We Keep Coding

parcel always caches no matter

I'm trying to run the example from an npm package that uses parcel.
The example uses a url that makes an api call.
To run the example I do: npm test
Below are the 2 attempts that I made to stop the caching. I modify the index.js, kill the local server and restart and it caches no matter what. I'm just looking to run the example and make changes and see the results. It is obviously using the dist folder, but I keep deleting things, but the issue still persists. Any suggestions would be appreciated. Feel free to ask why would I ever want to do this.
package.json
"scripts": {
"test": "parcel example/index.html --no-cache",
"patch": "npm version patch --no-git-tag-version",
"minor": "npm version minor --no-git-tag-version",
"major": "npm version major --no-git-tag-version"
}

It seems that although --no-cache technically does disable Parcel's aggressive caching, in practice it requires a few more awkward steps to actually see any new changes you've made.
In addition to running parcel with the --no-cache option, you also need to close or completely kill the terminals running any current instances of the parcel local server, and also need to bypass the browser cache by doing a hard refresh (CtrlShiftR in Firefox).

The docs for the --no-cache flag say:
Caching can also be disabled using the --no-cache flag. Note that this only disables reading from the cache – a .parcel-cache folder will still be created.
So my hunch is that it's working as expected. In most contexts it's totally fine to allow parcel to create a .parcel-cache folder (although it's best practice to add this folder to .gitignore). Is there something about your context that makes this a problem?

What is the difference between installing eslint as extension and installing as npm package?

I have been following various blogs and videos on setting up and configuring eslint and prettier for vscode and development. But every article fails to explain why do we need to separately install eslint as an npm package and vs code extension?
what difference it will make if I install either of the ones?

why do we need to separately install eslint as npm package and vscode extension?
Short answer: you don't.
Long answer:
Installing ESLint/Prettier as extension, allows you to format/check your code inside the VSCode.
However, installing them also as dependencies brings extra benefits:
VSCode will use exact same package as installed. So you will not spot the situation when VSCode says OK, but your CI server says: NOT OK
You will get control over the versions, and can update whenever you want
You will be able to use different versions for different projects. This is especially important, when you can't migrate old project, but want to use the latest possibilities for the new one
You will be able to access Prettier/ESlint through the script block of the package.json, and be able to write custom commands with parameters exactly as you need
You will be able to pair them with Husky or NPM hooks to automatically verify/format the code
From my experience, if you can install something locally - install it as package dependency (except CLI like create-react-app or angular-cli that helps you start the app). This will make your life a bit predictable.

These programs can format your code (ESLint and Prettier) and detect specific syntax (ESLint).
When installed as an extension in your IDE (vscode for example), you can get:
squiggly lines in real time;
and format-on-save.
But someone who starts up your project on their own environment might not have these extensions installed (might not even have the same IDE) and thus might not get these.
When installed as npm packages (and included somewhere in the pipeline, either in the npm start, or in your continuous deployment, or...)
you won't get real time squiggly lines,
but you can still get auto-formatting (though not necessarily on save, depending on the configuration),
you can get blocking rules (meaning instead of just seeing errors / warnings, you can actually block the pipelines until the dev fixes said errors / warnings)
you can insure anyone who starts the project, from any IDE, gets the packages included

npm install changes my package-lock.json, will that interfere with the remote code?

I know there are numerous issues about this, and I discovered the command npm ci that is supposed to not change package-lock.json, but when I run npm ci it fails:
ERR! cipm can only install packages when your package.json and package-lock.json or npm-shrinkwrap.json are in sync. Please update your lock file with `npm install` before continuing.
Also tried another solution involving deleting my node_modules directory and running npm i again, but that's not changing the outcome.
I'm a junior dev working with a team remotely.. I was given a task, so I created a new branch on Gitlab, pulled it down to my local machine and ran npm i to get up-to-speed...
But it keeps changing my package-lock.json DRAMATICALLY(it adds like 20,000 lines of code)
Committing that to the team's project seems insane to me. Anyone have advice?

Update: OP wound up needing to make use of yarn which their team and project made use of. If anyone finds a yarn.lock in their project root, this is an indication that yarn is involved and any package-lock.json, if there is one, is possibly outdated.
TL;DR: it sounds like the package-lock.json needs some updates and resolution, which is done primarily with npm install.
It sounds like the package-lock.json no longer "agrees" with your package.json. It also sounds like others on your team are avoiding committing the changes to your package-lock.json; this is a bad practice in my experience as it only deepens any divergence in their contents. Over time they can be out of sync when dependencies of dependencies may publish a bug fix release and potentially un-publish a previous version.
As a junior dev on this team, I would bring this up to your development/team lead and ask their preferred approach here. If there was a major dependency intentionally removed and that has a lot of its own dependencies, it could cause a large removal of lines from package-lock.json and look severe to one less accustomed to it.
Extra context:
During an install, npm installs the dependencies and development dependencies listed in your package.json. In the process it's possible and increasingly likely over time, that some of the dependencies of those dependencies, which are needed to execute, will overlap and often with conflicting versions. The execution of npm i(nstall) will attempt to reconcile all these competing versions of sub-dependencies for you.
In a Continuous Integration context, it is desirable for the alternate command npm ci to be used, which explicitly installs only what's resolved already, from package-lock.json (the formerly known as "shrinkwrap"). This is meant to reduce the "but it works on my machine!" moments. As a developer, I've found it to be preferable to use npm install, as this alerts the developers more quickly to any dependency resolution issues and keeps the package-lock.json up to date.

Since this post got so many views I thought I'd come back and post what I found.
Yarn and NPM both update and install packages and dependencies, but the difference is:
yarn creates a file called yarn.lock
npm install creates a file called package-lock.json.
I didn't know this at the time, so when I cloned the project repo to my local machine, I ran npm i which created the package-lock.json. My teammates were already using yarn, however.
So make sure you use the one already being used.

What's the point of having a "compatible version" (^version) declared in package.json if package-lock.json locks it?

I know the main advantages of package-lock.json and I agree with that. It not only locks the downloaded version in the last install, but also the uri... and that's required on most cases for being possible to replicate the most similar project as possible.
But one thing that seems weird to me is that package.json has the feature of declaring a dependency like dependency: ^1.0.0, that should make npm to download the most recent and compatible version of that package in each installation.
I'm working at a project that I actually need this. Otherwise every time my dependency releases a patch, it will be required to make a new commit updating package.json only changing the version, so my pipeline can also overwrite package-lock.json.
In short, it seems that while package.json uses a feature... package-lock.json prevents that one.
Am I missing something?

The point of package-lock.json is to accurately represent the tree as it actually exists at a point in time, so that someone cloning the project gets exactly the same tree you had.
If you want to upgrade that dependency to a newer version, just use npm update and then commit the updated package-lock.json. Other members of your team will get that update as part of the normal process of picking up the latest.
More in the npmjs.com page on package locks.
Let's consider as scenario where you and I are on a team and our project uses nifty-lib, with package.json saying "nifty-lib": "^0.4.0", and we don't share package-lock.json. Perhaps I've been working on the project a couple of months longer than you have and I got nifty-lib v0.4.0 when I installed it. But when you picked it up and installed, you got v0.4.1 (a bugfix update which, sadly, introduced a new bug). At some point, you notice what seems like a bug in our project, but I can't replicate it. We spin in place for a while trying to figure out why it happens to you and not to me. In the end, we realize it's because it's actually a bug in nifty-lib that they introduced in v0.4.1. Hopefully we then get 0.4.2 or something (or if there isn't one, we fix the bug and do a PR, meanwhile rolling back to 0.4.0 across the project).
If we'd been sharing package-lock.json, we wouldn't have spun in place wondering why the problem happened to you and not to me, because you would have had the same version of nifty-lib as me. As part of our normal cycle, we'd do npm update periodically, and if a new bug showed up in our tests, we'd know from the commit history that it was because of a bug in a dependency.
Now, for "me" and "you" read "dev" and "production". :-)
Which is why package-lock.json locks the version, but package.json lets you say "this or better". package-lock.json keeps your team unified on versions, but you can intentionally update with npm update, which shows up in the commit history so you can track down regressions to it.

As I mentioned in a comment above, the short answer is it makes updateing your dependencies easier.
However, another way I like to think about the two files is: package.json is the file the human reads, while package-lock.json is the file the computer reads.
NPM is a package / dependency manager. So, in your package.json file, you write out "these libraries are needed for my library to work." As a feature, you have a range of versions you can list a dependency at. This helps when you run npm update on a specific package. It'll look to see what is the latest version that matches within your *package.json**, and updates you lockfile.
The package-lock.json lockfile is useful because it verbosely describes what your node_modules/ folder looks like so it can be accurately recreated when someone else installs your library. Additionally, since this file is generated automatically, you don't have to worry about maintaining it.
Of course, all of this just happens to be how NPM (and conversely how most package managers) handle this. That is, there isn't a technical reason why we couldn't have one file to describe both the version range that would be allowed when running updates, and a verbose lockfile portion that pins versions to allow for a recreatable dependency tree.
Basically, it is just a convenience. You have one file to succinctly list what dependencies your projects needs. It is readable and easily updatable. The other file, the lockfile, is automatically generated and ensures each npm install gives you the exact same node_modules/ folder as before.

Is bad practice to run "bower install" when deploying in production?

I am working on an application that uses bower.js; it's the first time I use bower, so please correct me if you see anything evidently wrong in my problem description.
------------------------------------------------
Coming from a Ruby background, I expect a package manager to have a .lock file, tracked under git, that tells me exactly which are the versions currently in use. This doesn't seem to happen with bower (am I right?).
A couple of days ago I deleted and re-cloned my repository, and ran bower install, thinking that such command would just install the required versions of the js components.
Then, today I did a one-line fix in a javascript file, compiled application.js using grunt watch, and realised that application.js was automatically filled up with tons of new code from bower component updates I wasn't aware of.
I found out that our bower components were under .gitignore, and that bower install, that I had run a few days ago, had actually updated two components without me noticing it.
When I realised what was happening, I immediately looked into our deployment procedure, which I paste here:
bundle install --path ${SNAP_CACHE_DIR}/.bundle
npm install -g bower grunt-cli
bower cache clean && bower install && bower list
bundle exec cap [our application name] deploy
Is this dangerous? Will bower install update all the components, that are likely not updated in my local version and are not tracked by git, ending up having completely different js code in production?

Is this dangerous? Will bower install update all the components, that are likely not updated in my local version and are not tracked by git, ending up having completely different js code in production?
Yes, this may happen and can cause problems. Although the impact will be limited as long as your dependency versions are specified as e.g. "~1.2.3", which will lock the major/minor version and only allow patch level updates.
In contrast to bower, the package manager normally used in node.js environments - npm - has a feature/command called npm shrinkwrap, which creates an npm-shrinkwrap.json file which locks down your dependency versions so that it is safe to run npm install afterwards.
This is probably what you would want.
However, bower as it stands does not have this feature yet - there is a discussion about it going on on Github e.g. here.
I think there currently are the following options to solve this problem in your situation:
Un-ignore and commit your bower_components (very ugly because of the huge amount of noise this produces in git).
Specify your dependency versions down to the patch level, e.g. "1.2.3" instead of "~1.2.3".
Culprit: If your dependencies have sub-dependencies, they might still be specified on the minor-version level, which means that even if your direct dependencies have a predictable version, your transitive dependencies may not.
Stop using bower and use npm instead (interface-/usability-wise, they are almost identical imho) and use npm shrinkwrap to lock down your dependencies.
Cheers, Alex