I would like to fork Facebook's Create React Repo and use it as a dependency instead of their own react-scripts. All tutorials on the subject publish the forked repo to NPM to install via the normal way.
However, my client would prefer to not do that as both the forked Create React App and my React App repositories are hosted in the same Azure workspace.
I know CRA is a monorepo and uses Lerna. Does that make it possible?
You could upload the package to a online git repository like GitHub. It can even be private if you want. The command to install it would then be: npm install --save-dev github:username/repo-name
If you're gonna make the repo private then you need to have SSH keys setup on GitHub and on all machines on which you will be installing the dependency on.
You could also install the dependency as a path if it's on the same file system but I have bad experiences with that so I don't recommend it.
I've personally done that at a previous organisation. We copied any package that we forked, when heavy changes were necessary, inside our monorepo. Lerna (or yarn, or what ever) takes care of the rest.
If you have a lerna monorepo, you'd take the content of https://github.com/facebook/create-react-app/tree/master/packages/react-scripts into your monorepo, in say: packages/custom-react-scripts and change the name of the copied package in the package.json
If you'd like to rename react-scripts binary into custom-react-scripts you could do that as well via the "bin" configuration inside the copied package.json
All the renaming steps are of course optional, but it helps to know that you're not using the official tool.
Related
I inherited a monorepo with a packages folder that has every existing package. I want to add a main package that is required by my panel package. panel already exists at version 0.34.0. Seeing as I merge to my repo without publishing a new version all the time, I want to create main at 0.34.0.
I tried going into packages/main but doing npx lerna publish only wants me to do 0.34.1 so I am worried if I try to do custom 0.34.0 I will break something. I tried npx lerna boostrap but it even says it goes to root doesn't ask for me to do anything in regards to brand new package in existing project.
Do I need to create the package and bump my whole monorepo to 0.34.1 via publish to then let any existing package use it?
I use symlinks locally, but when I go to make a PR, my CI will run yarn install which (I don't think) would find the packages when reviewing the package.jsons. Therefore, I don't think Using Lerna with unpublished packages applies here? I think I need to actually publish a version that can be referenced?
Going into the new main folder and typing npm publish - and just skipping lerna, is what worked. Found that out here: https://github.com/lerna/lerna/issues/1691.
Everything went where I expected and then I could just manually update package.json files as needed that are using the new package.
Is there a way for Hot Reloading to occur on a local npm dependency of a local Vuetify application using yarn serve (which is probably using webpack / vuetify-loader)?
BUSINESS CASE
We have some common Vuetify components that I'd like to expose with a "common-components" Vue Plugin and allow all of our Vuetify applications to pull those common components. I'm able to do so by packaging the plugin and creating the dependency and pushing to a private npm repo or a commit/push to a private git repo. The problem lies with the development cycle and development experience.
A typical development change to the Plugin within the local development environment requires:
(common-components) yarn build (to create the dist/common-components.umd.js)
(common-components) (deploy to a private npm rep or a commit/push to a git repo)
(application A) yarn upgrade common-components to pull the latest
(application A) yarn serve
There has to be a better development cycle than this, right? Or is my real problem that we need to decouple the plugin from our applications better?
THE SOLUTION I WAS HOPING FOR, BUT FAILED
yarn-link or npm-link
I was able to get this to work, but a NPM dependency still resolves to the folder's package.json which has a "main": "dist/common-components.umd.js". This requires me to do a yarn build which removes the file and rebuilds it. When the file is removed, "application A" that is currently running with yarn serve breaks and is unrecoverable. I must shut down the server and do a yarn serve again.
I'm hoping there is a solution out there that tackles this scenario!
I've done that kind of setup a while ago thanks to yalc.
It was essentially:
work on your own package, setup it (with yalc link if I remember properly)
when an update was done on the package, we had it to automatically yalc publish --push --changed like with a linter
you can use a pre-push git hook to babelify your package
on the host main app, we had a nodemon running to check if yalc published any changes, and if it was the case, simply reload the app
on main app still, we used a git hook on pull to have it fetching the latest changes on the yalc.lock store (with yalc update)
I did it a while ago so I don't remember it super well but it was working pretty well as far as I remember, just need to run 2 servers (one on the package to publish and one on your main app to fetch the changes) on top of your other services. Still works better than it's yarn or npm links.
According to the docs, Titanium now has support to install npm packages: http://docs.appcelerator.com/platform/latest/#!/guide/Node.js_Support
However, upon reading it, I am very confused as to where to actually put my node_modules directory. There is some mention in the docs about a Resources directory, however, for Alloy this is supposed to be left empty, as it is frequently overwritten by the compiler.
So my question is, where do I put my node_modules and how do I reference it.
In Alloy project you are supposed to run npm install inside the app folder. But according to this bug JIRA Ticket modules that use core-modules won't work correctly. So you have to try if you module works.
Another explanation: https://stackoverflow.com/a/45041737/5193915
From experimentation, it seems like you can do npm install in the app/lib/ so your package are in app/lib/node_modules. This does NOT work on the app/ directory.
Note that if you use tishadow, you will also need to install the npm packages there as well in the Resources/ directory (as they still do not use the Alloy framework).
I've built out this simple library https://github.com/FarhadG/script-tag-data and you can either clone it down or install via bower but I'm curious how I should go about turning it into an npm, browserify, etc. module.
Since you already have your project on github, for publishing to npm, you can follow the guide over here : npm-developers
AFAIK, browserify doesn't have a registry. You probably meant bower. Follow this guide : Creating Packages
And maybe use Google search next time, yeah?
Can someone explain to me the difference between NPM, Bower and Composer.
They are all package managers - correct?
But when should each one be used?
Also, each one appears to have a json file that accompanies it, does this store all the packages you require so they can be installed by cmd line? Why do you need this file?
[update, four years later]
bower is deprecated, and should not be used anymore for new projects. To a large extent, it has been subsumed into node dependency management (from their website: "While Bower is maintained, we recommend using Yarn and Webpack or Parcel for front-end projects").
yarn came out of the wood as a better npm (fixing several of npm flaws), and this is really what you should use now, as it is the new de-facto standard if you are doing front-end or node development. It does consume the same package.json as npm, and is almost entirely compatible with it.
I wouldn't use composer at this point (because I wouldn't use php), although it seems to still be alive and popular
[original answer]
npm is nodejs package manager. It therefore targets nodejs environments, which usually means server-side nodejs projects or command-line projects (bower itself is a npm package). If you are going to do anything with nodejs, then you are going to use npm.
bower is a package manager that aims at (front-end) web projects. You need npm and nodejs to install bower and to execute it, though bower packages are not meant specifically for nodejs, but rather for the "browser" environment.
composer is a dependency manager that targets php projects. If you are doing something with symfony (or plain old php), this is likely the way to go
Summing it up:
doing node? you do npm
doing php? try composer
front-end javascript? try bower
And yes, the "json" files describe basic package information and dependencies. And yes, they are needed.
Now, what about the READMEs? :-)
https://github.com/bower/bower
https://www.npmjs.org/doc/cli/npm.html
https://getcomposer.org/doc/00-intro.md