Intro: I've generated two projects with vue-cli ~4.2.0:
parent-app - main project
dummylib - library which is imported by parent-app. Has a bunch of .vue components inside.
Currently, parent-app works fine in dev mode with dummylib being imported into it. All dummylib's vue-components are rendering ok.
Problem: I want to edit dummylib and see changes on the fly, as it takes place with parent-app: without having to rebuild it after each code modification.
My current library development process:
(dummylib): yalc publish - assuming it has been built already
(parent-app): yalc link dummylib
(parent-app): npm serve - start local development
Editing dummylib...
(dummylib): npm build - !!! Want to avoid this step !!!
(dummylib): yalc publish --push - After this, I see my edits from (4) being applied...
So are there any options to avoid (5)? I've also thought about monorepo, but decided not to have it currently.
Finally, got it working by adding:
"start": "vue-cli-service build --target lib --name dummylib src/main.js --watch --mode development"
to scripts section in package.json
Related
So I have a vue project with this script in the package.json:
"build-test": "vue-cli-service build --mode test"
In the project, I have .env and .env.test files.
Now, everything used to work fine, when I build using the "build-test",
it results in the .env.test configuration as it supposed to
Now, the problem started when I added lerna to the project.
I tried to add a script in the main package.json which basically calls:
lerna run build-test --scope #company/web-app --include-dependencies
But when I do it, it results in getting the configuration from the default .env file and not the .env.test file.
If I run the command "build-test" from the web-app folder, it executes as it should, with the right .env file used.
Anyone has idea what is the problem by any chance?
Thanks In advance
I got a big project that is a monorepo consisting of multiple scripts and libraries, its structure is the following:
package.json // "private":true
\packages
\comp1
\package.json // an actual component
\comp2
\package.json // an actual component
\comp3
\package.json // an actual component
I've made a monorepo.tgz using yarn pack.
Then I made a test app whose package.json look like this:
"scripts": {
// this is a script in one of the monorepo's components
"start": "ui-build --bundle --watch -p 3000"
}
"dependencies": {
"comp1": "../monorepo/monorepo.tgz",
"comp2": "../monorepo/monorepo.tgz",
"comp3": "../monorepo/monorepo.tgz",
...
but its not working, when I run start its complaining that ui-build: command not found.
How can I test this monorepo locally to simulate a published npm package as closely as possible?
Using npm link (or yarn link), you can 'install' the packages from your local development environment.
To do this, you first run npm link in the directory of the package you want to install, so in \packages\comp1. Then in your testapp, run npm link comp1. This will install your package. Repeat for any others you want to install.
More info:
https://docs.npmjs.com/cli/v6/commands/npm-link
https://classic.yarnpkg.com/en/docs/cli/link/
To import a file directly without using npm link or yarn link you have to prepend the path with file:. And I believe you would have to pack each file, but you can link directly to the path without packing it as well. Make sure to build it if you are linking directly to the local package folder.
For your example:
"comp1": "file:../monorepo/comp1.tgz",
"comp2": "file:../monorepo/comp2.tgz",
"comp3": "file:../monorepo/comp3.tgz",
or
"comp1": "file:../path/to/monorepo/packages/comp1",
"comp2": "file:../path/to/monorepo/packages/comp2",
"comp3": "file:../path/to/monorepo/packages/comp3",
After some research I've found that https://verdaccio.org/ is the best tool to test a library without deploying to an npm repository
I am developing vue project and syncing dist folder with git. This worked well while using webpack. However, I have moved to #vue/cli --- using vue create myProject instead of vue init webpack myProj.
The issue is that every time i run npm run build, it deletes dist folder and recreates it -- all .git and other files gone.
How do I prevent new build from deleting required files in dist folder and only update the changes?
Assuming you have your own mechanism for cleaning up the old resources, vue-cli-service build comes with this option called --no-clean to instruct the compiler not to remove the "dist" directory before building the project.
So, add the switch/option to the build script on package.json:
{
"scripts": {
"build": "vue-cli-service build --no-clean"
}
}
Alternatively, if you use Yarn, you can pass additional argument(s) right after the script name. So there's no need to make any change to the script. To run it:
yarn build --no-clean
Thanks to answer by Yom S. the documentation here does provide way to keep older dist.
However, the you can't use --no-clean like npm build --no-clean. To use no clean mode from terminal you need to write following command instead
./node_modules/.bin/vue-cli-service --no-clean
Update
Instead you can also add --no-clean in package.json
Disclaimer: I am primarely a backend developer with no extensive FE knowledge.
I am writing a non-SPA Golang web application that generates HTML, which is then sent to the user.
Because I'd like to update and monitor my Javascript/CSS dependencies better, I want to switch to using NPM with a package.json file instead of manually downloading and appending CSS and Javascript libraries. These are the typical jquery, bootstrap and fontawesome.
In addition to this, I have a single Javascript file per page for interactive content.
e.g.
+ js
lib.js -> jquery, bootstrap, fontawesome
- home -> specific JS
- account -> specific JS
...
+ css
theme.css
custom.css
However, I see no simple solution to just npm install and export the installed packages to a vendor.js file, minified.
Iv'e looked at webpack (go-webpack), but this horribly complex with the whole tree shaking, bundling and shimming. In addition, webpack expects you to run a development server when serving assets locally, do some chunk magic and still refer to global libraries in every JS file. (to prevent from being tree-shaken away)
Is there an easier way to go from a package.json file to a minified, bundled set of assets?
TLDR: ‘You can’t see the forest for the trees’ - Just get a minimal configuration of webpack.config.js working before diving into more advanced details, such as tree shaking, chunking, etc...
You need to use a bundler, such as Webpack or Parcel, to bundle all your JavaScript assets into a single JavaScript file. I think you're trying to do too much to start with:
webpack-dev-server
Tree Shaking
Chunking
As these are more advanced concepts... Perhaps you could start by initially creating a single JavaScript bundle (or a bundle on a per page basis) to be used by your application. This wouldn't be as complex and would require entry points into the following files within your application:
Application's JavaScript index (This should load the JavaScript used by your application)
CSS index. (Ideally, you have a root styling file which loads other application styling files)
Now set-up the appropriate loaders and plugins for your application's assets, such as the MiniCssExtractPlugin, file-loader, etc..., to load and handle your applications' assets. Once everything is working, simply attach this generated bundle in a <script> tag within your root html index page, rather than initially configuring a webpack-dev-server. This will allow your application to use your bundled JavaScript file without the need to configure a webpack-dev-server. To create new bundles create custom commands within the scripts section of your package.json file, something along the lines of:
"scripts": {
"test": "echo \"Error: no test specified\" && exit 1",
"build": "webpack -p --progress --config webpack.config.js",
"dev-build": "webpack --progress -d --config webpack.config.js",
"watch": "webpack --progress -d --config webpack.config.js --watch"
},
Only after everything is working should you worry about more advanced performance gains, such as: chunking/treeshaking/etc... Take a look at the following tutorials as they may help: Intro to Webpack and Full Stack Web application. Note the second tutorial is a little dated as the defacto now would be to use create-react-app cli instead of setting up the build configurations yourself for a react project, BUT the principles are sound and show you how to go about setting up your own build configuration.
Hopefully that helps!
I have two Expo (React Native) apps that share most of their code and are already in production. We are trying to move them to a monorepo directory structure as follows:
lerna.json
package.json
packages/
mobile-1/
app.json
index.js
package.json
mobile-2/
app.json
index.js
package.json
mobile-common/
src/
... actual app code ...
index.js
package.json
The way our setup works is that we export a function that starts the app from mobile-common/index.js and mobile-{1,2}/index.js are supposed to call this function with initialization parameters specific to each of them.
The problem with this setup is that mobile-common makes use of react-native and expo dependencies, which are also required by exp to start the React Native packager which causes certain issues at build time. We tried the following:
Adding mobile-common, expo and react-native to the dependencies in mobile-{1,2}/package.json and doing lerna bootstrap. This allows us to run the packager but mobile apps crash while building because they find duplicate dependencies.
We never got yarn workspaces to work, either.
lerna bootstrap --hoist also did not work.
npm link also produced issues at build time with duplicate dependencies.
We really want to move to this kind of structure because our previous structure didn't easily allow us to run both apps side by side, and it is becoming increasingly necessary.
Thanks for helping us out!
If you want to setup expo with a monorepo you can look at my example here.
Currently the expo packages must remain in the root package.json because of limitations with watchman not resolving symlinks properly.