Is there a way I can make vite build in my Vue 3 project only build the latest commit on the current branch, as opposed to the exact current state of the branch?
Related
I am in the process of creating a React app (using Linux-Ubuntu, npm 3.5.2, node v8.10.0, with npx). I used the following-
npx create-react-app my-app
But to start the app:
npx start
I got a bit of errors (shown below)
There might be a problem with the project dependency tree.
It is likely not a bug in Create React App, but something you need to fix locally.
The react-scripts package provided by Create React App requires a dependency:
"eslint": "^6.6.0"
Don't try to install it manually: your package manager does it automatically.
However, a different version of eslint was detected higher up in the tree:
/home/dirsomename/Projects/node_modules/eslint (version: 5.16.0)
Manually installing incompatible versions is known to cause hard-to-debug issues.
If you would prefer to ignore this check, add SKIP_PREFLIGHT_CHECK=true to an .env file in your project.
That will permanently disable this message but you might encounter other issues.
To fix the dependency tree, try following the steps below in the exact order:
1. Delete package-lock.json (not package.json!) and/or yarn.lock in your project folder.
2. Delete node_modules in your project folder.
3. Remove "eslint" from dependencies and/or devDependencies in the package.json file in your project folder.
4. Run npm install or yarn, depending on the package manager you use.
In most cases, this should be enough to fix the problem.
Well, it did not fix the problem even after following the steps above.
So, my goal now is to retrace my steps and to uninstall the complete React app from scratch.
How do I go about doing that?
I’m building a node.js app that needs to be scalable and maintainable. The idea is to have one repository, but with more than one module inside it.
We are using local modules with npm, but we have a problem is that when we update a modules npm won’t update the dependent services.
here an example of the package.json
// ./app/package.json
{
"dependencies": {
"error-lib": "file:../modules/error-lib"
},
"scripts": {
"start": "node app.js",
"debug": "node --inspect-brk app.js",
},
"main": "app.js",
}
// ../modules/error-lib/pacjake.json
{
"name": "error-lib",
"version": "1.0.0",
"main": "index.ts"
}
I have one problem when a developer updates the error-lib module, an npm install command won't update the old error-lib inside app/node_modules.
I don't want to bump the version of the modules on every change because they follow the same versioning and release lifecycle.
And I don't want to rm -rf modules manually every time.
Any idea on how to automate a repo with many local modules?
TL;DR (Why one repo, many local modules)
We came from a Java background, where we have a single repo multi-module architecture managed by maven.
What we do in maven is to isolate services, common-library, data model in isolated modules.
We have only one repo for all the modules and service since everyone follows the same release cycle with a uniform versioning.
When a developer needs to apply some change he or she can update one of the modules or the services and maven will take care of every dependency and the code will be up to date and ready to rock.
But we want separate modules for many reasons:
This will force us to decouple the functionality and make code reusable since every module can virtually be placed in a separate repo at any time.
If some module will become usable outside of the repo can be externalized and maintained.
We want to achieve the same design for a new part in node.js
Looks like you need $ npm link instead, creating symlinks to your packages within ./app/node_modules. This way, the linked packages are always 'up-to-date'.
Linking a package is a 2-step process:
$ npm link at ../modules/error-lib creates a symbolic package in your global node_modules folder under the name error-lib, specified in ../modules/error-lib/package.json its "name" value.
$ npm link error-lib at ./app to create the second link inside ./app/node_modules to <global-node_modules>/error-lib.
more about npm link
Edit in response to your comment:
I've seen some drawbacks of npm link:
the dependency is not listed in the app package.json, so how I know which dependency I'm linking?
the node_modules is not committed on the repo, so the CI/CD will need to do the linking while listing modules/error-lib inside the app package.json I have a place to take track of the dependencies.
There is any best practice on how to automate npm link or to mitigate the drawbacks?
NPM packages are supposed to be distributed through the npm registry. This means that your error-lib package also should be distributed this way, and be installed as any other package. This will require you to list your package in the package.json file in advance, which is essentially what you want.
If you instead intend to keep everything in one place there is no use in using NPM at all. Just resolve your packages with relative import paths in your software.
Since you said that all the packages follow the same release cycle as your main software, and they live in the same repo, why would you resolve these packages with NPM while they seem more like just part of the software?
error-lib is either a package, or it is not. If it is, it ideally has its own CI/CD pipeline, as large or tiny as required, involving testing, building and distribution. This pipeline is then to be run before the pipeline of your dependent repositories.
I'm developing a react component, and it depends on an ES6 component I'm also developing which I wrote first.
What's the normal way to include this at dev time while I'm working on the second component. Obviously, if the dependancy was in NPM it would be in my node_modules and I'd just import it.
I don't want to reference it by path as I'd have to remove that path every time I commit or publish.
Is there anything that would watch for changes in Module A and update the dependancy version in Module B?
Are your React component and ES6 component separate modules?
If so, you can use npm link.
First, go to your ES6 component's directory and run npm link. This will set up a symlink in your Node packages to the local version of your component.
Then, go into your React component directory and run npm link <es6-component-name>. This will create a symlink in your node_modules to the linked version of your ES6 component.
This only works for local development, obviously. If you want to distribute your React component and have it depend on your ES6 component separately, you'll need to publish them to NPM separately and add one as a dependency of the other.
I'm attempting to update my Phenomic install to webpack 2 beta 13 (I've heard people suggest the beta is pretty stable now).
I get the follow error when trying to build version using the DedupePlugin, but it seems to work if I remove it. The error is:
phenomic:builder ChunkRenderError: No template for dependency: TemplateArgumentDependency
at Compilation.createChunkAssets
Phenomic includes webpack itself and sets up part of the config. You can run a build using Phenomic and it will also take custom webpack settings from your own generate project. A default project is created for you to modify when you initialise Phenomic.
I've tried changing the version numbers to "webpack": "2.1.0-beta.13", under Phenomic's peer and normal dependencies and rebuilding with it npm linked. I also made a few of the changes needed for updating webpack 1 to version 2.
I've also deleted node_modules in both Phenomic and my project directories, which did not seem to help (and took a long time ;).
I've browsed through this thread which was webpack 1 related and there is some suggestion of dependencies causing multiple copies of webpack. Any ideas are appreciated.
Update:
I made my webpack 2 changes in Phenomic and setup the default project. It seems to build (with some CSS issues), so the problem seems related to the more complex project I am using Phenomic with. Maybe another dependency is bringing in another copy of webpack.
It seems this is npm link related as I installed installed Phenomic from my file system and the issue disappears.
I also noticed there was a global copy of Phenomic, which is also possibly related to npm link.
Another tip I found was npm ls is useful finding what dependencies are in use. You can pipe the output to a file if you want to read it in an editor.
Is there a way to create a meta-package, which package.json:
a) contains a list of dependencies, which are not used to build this
package;
b) enforces NPM to install these deps, when this very
meta-package is added to the project, both for production for the development?
The problem is that I have a few dozens of packages (both, prod and dev) in my boilerplate, which I copy from project to project. I would like to have one private package, which once added to project's package.json tells npm which other prod and dev deps to install. I want to improve the process of using the boilerplate, because when I change something it it, I have (actually that is my will, not the enforcement) to make these changes in all the projects built on the base of this boilerplate and which are still in development.
I have managed to add all the deps I usually use to production section of my meta-package's package.json. However there are two problems with this approach:
1. A lot of unnecessary packages are installed when I build the meta-package (I have to build it as it contains some helpers in ES6/7);
2. I still have to copy/paste the list of production deps into every new project to provide NPM information, what to install on the production server.
Non-npm solutions are welcome as well.
Well, it appeared to be quite easy to do:
1. First of all, it is required to split all the packages used in the boilerplate into two groups - required to run the app (production), and required to build and debug (development).
2. Create the production meta-package (meta-prod). package.json content:
...
"dependencies": {
< Here we have the list of production dependencies. >
},
...
Compile it if necessary and push to git (i.e., github).
3. Create the development meta-package (meta-dev). package.json content:
...
"dependencies": {
< Here we have the list of development dependencies. >
< Please note, that this is in the 'dependencies' section, >
< not the 'devDependencies'. >
},
...
Push it to git.
4. Remove all the dependencies from the boilerplate's package.json and replace it with:
...
"dependencies": {
"meta-prod": "git+https://github.com/your_account/meta-prod"
},
"devDependencies": {
"meta-dev": "git+https://github.com/your_account/meta-dev"
},
...
That's it! Dependencies will be installed when you do npm install and will be properly considered by npm as production and development. Now you can use much smaller package.json boilerplate and update the list of your devs from the single point.
The only downside is that npm does not catch the version change when you use package from git, so to update packages within the app you have to remove meta-packages directories from node_modules and rerun npm install. To fix this you can publish your package to npmjs.com (better to publish it as private package if you are the paid npm customer) and change meta-package version every time you update it.
Here is the boilerplate and meta-packages example:
app boilerplate
meta-prod
meta-dev