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?
Related
There is a test and a production environment installed on a unix server. I got SSH and FTP access. I changed some *.js files in the test directory but the changes do not take effect in the frontend. Unfortunately I don't know so much about node.js and unix server but I now how to code JavaScript.
So here is my question: How can I "refresh" the test environment only (without affecting the productive environment and vice versa) so my changes take effect?
I searched many websites, read lots of articles and nodejs beginner guides but I don't know how to deal with this system who has been implemented by someone else I can't ask anymore.
Any help or hint will be highly appreciated. Thanks in advance!
EDIT1: All local browser caches have been cleared (Chrome development console no cache active and console open - refresh)
EDIT2: JavaScript files are executed on the server as part of a node.js application
You have stated that you are running server-side scripts, so try restarting Node.js. If you still have access to the terminal you are running from, press CtrlC, but if you don't, run pkill node or killall node (depending on your system and preferences).
To automatically restart your server when a file changes in the future, use nodemon. To start using it, it is recommended to set up your command line in an npm script named start. To do this, add this to your package.json:
"devDependencies": {
"nodemon": "^2.0.20"
},
"scripts": {
"start": "nodemon index.js"
}
We have a React project that is using Yarn for package management. I notice that Yarn sometimes tweaks versions in the yarn.lock file even though nothing is changing. For example, when I run yarn install, it wants to make the change from:
yarn#^1.21.1:
to:
yarn#1.21.1, yarn#^1.21.1:
I don't quite understand why since the versions are the same. It flip-flops on this change quite often and it just depends on what packages we're installing. This example is for the yarn package itself, but it does this with a few different things.
Does anyone have any insight into why this is happening? Is it an issue with one developer's setup vs. another developer's setup? It's incredibly annoying because every time I sync my branch, run a yarn install, it wants to make changes to our lock file when I don't think it should be doing this.
Edit:
We also have this in our package.json file:
"resolutions": {
"yarn": "1.21.1"
}
I've been building websites using a normal LAMP stack with javascript (and jQuery) for the frontend for quite a while. But I wanted to try using javascript for the backend as well. I'm just starting to learn next.js.
On the old way, if I have modified a php file, to see the effect I can just refresh the web browser. But I noticed that with next.js you can't see the change immediately. I have to stop the npm script, rerun the "npm run xxx" command, then refresh the browser. It's kind of time consuming.
Is there a way to automate this process?
#Rudi's answer is correct, and I'll add to that that you want to make sure the command you're ultimately running is next, not next start. The difference is that next is for development mode, whereas next start is for production mode. In production mode, it doesn't watch your files for changes.
Typically, you have these commands referenced in the scripts section of package.json:
{
"scripts": {
"dev": "next",
"build": "next build",
"start": "next start"
}
}
And then the command you would actually type in and run would be npm run dev for local development or npm run build; npm run start for production mode.
If this doesn't hold for your usage, and you have to restart the server even in development mode, then there may be something wrong with your setup.
One common issue that causes this has to do with accidentally importing a component and making a minor typo with lowercase/uppercase naming conventions.
For example, you import a component named Navigation, as navigation.
This will still import Navigation, but the live reloading will be broken.
In development mode, Next.js by default will hotreload any changes, you don't even need to refresh the browser.
But if you add a custom server, it doesn't hotreload changes to that. You can use nodemon to watch and restart the server: https://github.com/remy/nodemon
On the face of it, mocha being in devDependencies like the tutorials say, is logical enough, it is after all a dev dependency.
But in practice you install it -g so you can run mocha as a command. And as far as I can tell, given that, it makes no difference at all whether it's mentioned in your package.json.
So is there any need to explicitly list it?
If you're working on an open-source project, one of your goals could be to allow other developers to be able to start contributing quickly.
One of the things that will help a lot is the possibility for a new developer to quickly be able to build and run your project, as well as run the tests. In order to do that, you can provide an easy way of installation of all the tools that a developer should have in order to contribute to your project.
This includes:
Build tools
Testing tools
Code quality tools (linter)
On the other hand, a user of your project is likely not going to need any of that, which is a good reason to split dependencies and devDependencies.
On top of that, it's useful to edit your package.json to provide useful scripts so that you can, for example, run npm test. It's common to specify something like:
{
...
"scripts": {
...
"test": "mocha -opts mocha.opts ...tests..."
}
}
Then npm test is going to run the specific mocha from your node_modules.
If you install it globally, that's a single version across all your projects.
If it's a dev dependency, each project can be using a version specific to that project, and the project can migrate to newer versions in a controlled way.
Pretty much the same argument as for having other modules loaded project-specific rather than globally.
Because you don't need to run mocha as a command. You can run it from node_modules like so: ./node_modules/.bin/mocha.
Npm has special support for this. If you have the following in package.json:
"scripts": {
"test": "mocha"
},
"devDependencies": {
"mocha": "*"
}
Then you can execute npm test even if you don't have mocha globally installed.
So, what's the use of this? First of all it's a nice thing to do if you collaborate with other developers - they don't need to do anything more than npm install to set up the development environment.
Second, and I think more useful, is this makes it easy to integrate your project with other tools like Travis etc.
I want to ask this question is because I met some problems when I co-work with other developers.
Sometimes, other developers update node modules version, and I pull the new commit and forgot to install new modules.
It would cause some problems when run the code. And I didn't realize the bug was caused by update module version at first. It took me some time to debug in wrong way.
Is there any method to solve this problem?
Like compare your local node_module with your package.json setting.
I think of one way is to create a git plugin. This plugin will notify you when package.json changed.
I also try to find some modules but what these modules do is to compare local version to npm registry version. (like npm-check-updates)
Is there anyway to compare local node_module with package.json setting?
I think it will also help when deploy the code to production mode.(to do the pre-publish check)
2 things:
If want to be notified when the package.json has been updated, I think the standard git pull command should be enough as it displays all the file updated by you co-workers commits.
If you want to avoid launching your dev environment with some missing dependencies, I think the best way is to add a grunt (gulp,or any other task runner) install-dependencies task that will be required for your grunt serve command.
Doing so, you'll never miss a package.json update, and this will force you to maintain all your local dependencies up-to-date and homogeneous with your team.
hope this help