I have installed "#vue/cli-plugin-pwa": "^4.5.12", in my package.json, I have also added workbox configuration in my vue.config.js. The problem is, when I'm building the project with npm run build:prd which has my script: vue-cli-service build --mode prod.example, there is no service-worker.js in my dist folder.
this is my vue.config.js:
module.exports = {
// ...other vue-cli plugin options...
pwa: {
// configure the workbox plugin
workboxPluginMode: 'InjectManifest',
workboxOptions: {
// swSrc is required in InjectManifest mode.
swSrc: 'src/service-worker.js',
// ...other Workbox options...
}
}
}
I've tried to move the pwa plugin configuration inside package.json, but it doesn't work as well. I just can't find my service-worker.js in my dist folder.
The current workaround is I place my service-worker.js inside my pubic folder. The problem with this approach is that the service worker will not be updated at all every time there is a new release. Currently the purpose is to notify the client if the new version is available, but I can't trigger the update event because the service-worker.js is static
I found the problem, #vue/cli-plugin-pwa will only generate service-worker if process.env.NODE_ENV === 'production'. meanwhile in my project, when i run npm run build the NODE_ENV is not automatically set to production but it's still development I don't know what is causing this behavior, but the problem is solved if i add NODE_ENV=production in all of my .env. With this, precache-manifest....js will be generated on every build.
Related
I can't get Next.js' Fast Refresh feature to work with a VS Code Remote Container. I can run npm run dev and see the app running on localhost on my machine, so the container works fine - only the Fast Refresh has no effect at all.
Next.js version: v11.0.1
I tried this both with Windows 10 and Ubuntu 20.04 (on WSL 2).
I already tried to use a custom webpack middleware in the next.config.js like so (see https://github.com/vercel/next.js/issues/2179#issuecomment-316568536):
module.exports = {
webpackDevMiddleware: (config) => {
// Solve compiling problem via vagrant
config.watchOptions = {
poll: 1000, // Check for changes every second
aggregateTimeout: 300, // delay before rebuilding
};
return config;
},
};
...which will trigger a recompile on code changes, but the browser does not update.
Also, the requests to "HMR" are failing:
How to reproduce:
Install the Remote Containers extension
Open any new folder
Open the command palette and type/select "Remote-Containers: Rebuild and Reopen in Container"
Type/select "Node.js"
Type/select version "16" and wait for the container to start
Go to the .devcontainer folder and open the devcontainer.json
Edit the config by adding "forwardPorts": [3002], to make the app available on your host and rebuild the container (via VS Code's command palette)
From the terminal, install Next.js, e.g.: npx create-next-app --use-npm --example with-typescript-eslint-jest my-app
Move all the files from my-app to your VS Code project root folder. This has to be done because create-next-app does not work installing in the project root folder via ., because there's already the .devcontainer folder.
Optional: Create a next.config.js and add the snippet for the Webpack dev middleware as seen above
Edit the package.json script to use a specific port: "dev": "next dev -p 3002", (or, if you use WSL 2: next dev -p 3002 -H ::)
From the terminal, start the app npm run dev
Open the browser on http://localhost:3002
The app is showing. Make changes in the code -> even a recompiled app will not show the changes in the browser. A reload of the page in the browser will show the changes though.
With Create React App, there's an advanced configuration without ejecting (called CHOKIDAR_USEPOLLING), which makes their Fast Refresh work with Remote Containers.
Earlier I created a feature request, but maybe someone already managed to make this work without huge changes in the configuration/setup?
A lot has changed between me noticing this issue and the current version of Next.js (v12.1.6).
I just tried it out again and it finally seems to work! 🥳
I'm going to change my Next.js projects to use devcontainers and maybe other stuff does not work, but at least for Fast Refresh, this topic is solved.
If you're following the steps above, the most basic setup should look like the following. It is based on the default "Node.js v16" devcontainer preconfiguration.
You don't even need to forwardPorts anymore!
// For format details, see https://aka.ms/devcontainer.json. For config options, see the README at:
// https://github.com/microsoft/vscode-dev-containers/tree/v0.234.0/containers/javascript-node
{
"name": "My project",
"build": {
"dockerfile": "Dockerfile",
// Update 'VARIANT' to pick a Node version: 18, 16, 14.
// Append -bullseye or -buster to pin to an OS version.
// Use -bullseye variants on local arm64/Apple Silicon.
"args": { "VARIANT": "16" }
},
"settings": {},
"extensions": [
"dbaeumer.vscode-eslint"
],
// Use 'forwardPorts' to make a list of ports inside the container available locally.
// "forwardPorts": [],
// Use 'postCreateCommand' to run commands after the container is created.
// "postCreateCommand": "yarn install",
// Comment out to connect as root instead. More info: https://aka.ms/vscode-remote/containers/non-root.
"remoteUser": "node"
}
I'm using the vue-cli tool to develop vuejs apps, and I'm developing a server too, so i want to build the /dist folder in my server to send it to the browser as static, but I don't even know where the /dist folder is.
There is a webpack.prod.config.js file (I think is the webpack config for production) and in the path-output field I tried to wirte the path but didn't work.
/dist is just a default setting by VueJS. If you want to modify this : as the documentation from VueJS states :
Always use outputDir instead of modifying webpack output.path.
Create a vue.config.js as an optional config file that will be automatically loaded by #vue/cli-service if it's present in your project root (next to package.json).
The file should export an object containing options:
// vue.config.js
module.exports = {
// options...
}
As otheres already stated in the comments, use outputDir to specify the directory where the production build files will be generated in when running vue-cli-service build. Note the target directory will be removed before building (this behavior can be disabled by passing --no-clean when building).
// vue.config.js
module.exports = {
outputDir : ''
}
I have a Webpack-templated Vue project, initiated through vue-cli.
I have created a simple 'vue.config.js' file stored in the root folder (where package.json is at) containing the following:
// vue.config.js
module.exports = {
productionSourceMap: false
}
Though when building the project using "npm run build" it ignores it.
I have tried different configurations to check if the problem is with the file or the setting, and the problem is with the file.
I am using webpack#3.12.0, vue#2.6.11, #vue/cli 4.2.3 and npm#6.9.0.
Make sure your build confiuration (in your case the webpack build configs) include your file.
Generally, you will have a source folder (often src) and the builder will build all the files in that dir only. Then you have your destination directory (often dist or build) where your build files will be stored.
Two solutions:
add your conf file to the build source.
move your vue.conf.js file into your source directory
For some reason, I did not manage to get vue.config.js to work.
Alternatively, I edited my webpack config, which as my build files mentioned was located at /config/index.js
Then, I proceeded to pass my build configurations to the build parameter which already appears on the file.
build: {
...
}
And it worked. I assume it may be because I used npm run dev instead of the vue-service-cli, so webpack did not go through the vue.config.js file.
I want to create a plugin so that I can raw-load a certain type of file with parcel. Parcel docs states that:
Publish this package on npm using parcel-plugin- or #your-scope/parcel-plugin- prefixes, and it will be automatically detected and loaded as described below.
...
Any dependencies listed in package.json with these prefixes will automatically be loaded during initialization.
Since this is a one-time thing, I don't want to publish the code on npm as a plugin. How do I load my project-local plugin with parcel?
Thanks in advance.
Since I could not find a way to do this in a parcel way, I did this in an npm way:
I created a folder named local_modules (this can be anything you want.) Then created parcel-plugin-x inside local_modules. Inside that, I created my plugin as usual. I also created a package.json specifying the entry point main. You can specify the dependencies required for the module just like if this is a separate project (THIS IS!).
{
"name": "parcel-plugin-x",
"version": "0.1.0",
"description": "Parcel plugin x",
"main": "index.js",
"devDependencies": {
},
"dependencies": {
}
}
Directory structure:
project-folder---local_modules---parcel-plugin-x
|---package.json |
|---index.js
|---package.json
Then I ran npm i --save-dev .local_modules/parcel-plugin-x inside the project-folder. It adds the line "parcel-plugin-x": "./local_modules/parcel-plugin-x", to the root package.json. This is the standard way of loading local modules in npm. And everytime you make changes to the plugin, you have to run npm upgrade. You should also increase the version of your plugin, too. This copies the plugin to node_modules and install dependancies.
According to the parceljs docs:
Any dependencies listed in package.json with these prefixes will
automatically be loaded during initialization.
now it works! :)
I did something similar, but with npm link.
In plugin folder (parcel-plugin-x) just run: npm link.
In the project folder using the plugin:
Link to parcel-plugin-x: npm link parcel-plugin-x
In package.json file, manually add the dependency to parcel-plugin-x
package.json
"devDependencies": {
"parcel-plugin-x": "^0"
}
Each time you make changes to the plugin, you don't have to run npm upgrade, but you might have to remove .cache folder created by parcel, because parcel will skip processing cached assets.
I think you can do this with the workspaces option in package.json: https://docs.npmjs.com/cli/v7/using-npm/workspaces
This library seems to be implementing it: https://github.com/astegmaier/stackoverflow-parcel-namer
I'm using browser sync with an Angular SPA. Serving the site looks like this:
gulp.task('serve', function() {
browserSync.init(null, {
server: {
baseDir: './',
middleware: [historyApiFallback()]
}
});
});
This works fine. The use of historyApiFallback (npm module) means browser sync doesn't freak out when going to a new URL path when all it needs to do is continue serving the index.html.
The problem I have is with watching files. I've tried this:
gulp.task('watch', function() {
watch('./src/scss/**/*.scss', function() {
runSequence('build-css', browserSync.reload);
});
});
The watch task does work because the build-css task triggers fine. Then the console logs Reloading Browsers... and just hangs. The browser never gets the CSS injection or reload. What am I doing wrong here?
Note that I'm using gulp-watch not the native gulp watch purposely.
I recommend you to use the lite-server. It is a simple customized wrapper around BrowserSync to make it easy to serve SPAs(you don't even have to configure the history api).
You can use it by simple adding an entry in the scripts object in your package.json and running the following command: npm run dev.
"scripts": {
"dev": "lite-server"
},
The module will automatically watch for changes of your files and keep then sync. So it will work with your gulp, because it will update your browser after the build-css task is executed(because the output files will change).
I am currently using it with angular 1, angular 2 and vue.js and worked fine with all.