I have three packages inside standard lerna monorepo.
client
react library
core
Core - is a shared component library with some utils (may or may not publish on npm).
React library is component library which will be shared on npm.
client is a bundled js library which will be consumed in browser with static html files.
core is a dependency in react-lib as well as client
Question 1 - How to setup core, should I transpile with tsc and bundle with tools such as rollup or vite (i personally prefer vite/rollup over webpack). or just leave it as is and import it in client and react-lib with absolute paths like 'core/src/*"?
Question 2 - can i build core in 'es' format and build client just like normal react app with either cra or vite. I tried this but i think i am missing something as final bundle doesn't seem to work in browser.
Any help would be really appreciated.
You have a few questions and I might not be able to answer them all but hopefully enough to guide you for the solution you're looking for.
Core - is a shared component library with some utils (may or may not publish on npm).
If you want to use Lerna then I guess you'll have to eventually publish the package on npm or a private repository. As an alternative, you could also use pnpm workspaces and their workspace: protocol which will allow you to link the packages in your workspace (monorepo) without ever downloading them from npm, for example if you use workspace:* then it will always use and link to the latest code from your local workspace. You could also use workspace: protocol with Lerna (or Lerna-Lite) since they both support it.
For your next Questions, I'll answer the last part of your Question 1 first because that affects the other portion of the question.
Question 1: ...or just leave it as is and import it in client and react-lib with absolute paths like 'core/src/*'?
Use absolute paths outside of the package is not a good thing to do since it will only work on your local project and you cannot publish that to npm since it will be broken for the other users. It's better to stick with the workspace and let the package use the main or exports entries defined in your package.json. In other words, it's preferable to always build/transpile and let your other package use the transpiled code and if you need to debug then make sure to also include sourcemap
Question 1: How to setup core, should I transpile with tsc and bundle with tools such as rollup or vite (i personally prefer vite/rollup over webpack)
It probably doesn't matter which one you use TypeScript, Rollup or WebPack, In one of my project I use TypeScript in watch mode, it will auto-transpile whenever you change your code, the downside is that the more packages you have then the more TypeScript threads are opened in watch mode (1x per package) but in your case if you only have 3 then it's fine, there's also this TypeScript issue that I'm following which will hopefully bring multi-threaded compilation in the future. You could also use Rollup and the concept would be the same, use it in watch mode for each package (I've done it with Vite/Rollup using vite build --watch
as explained in the next paragraph).
You can take a look at a project I've done Vue 3 and pnpm workspace using pnpm workspace with the workspace: protocol, it uses Rollup for transpiling and also uses Vite library mode which allows to bundle your library for distribution (on npm or others...), this allows you to bundle each package as a lib that is easily reusable by other projects. It's a Vue 3 project, so it's not a React project but it should give you enough ideas on how to do in React and it should help to answer your Question 2. Also that project is not using Lerna/Lerna-Lite but since it uses the workspace: protocol then it would be super easy to add Lerna on top of it in the future (basically just adding the lerna.json config should be enough)
Related
I am new to npm, react and webpack but I have a question. In npm how do you prevent a library from being included production package file?
For example, I am just building a very small component in react and on the site where I am going to place my small component. The problem is Jquery library and bootstrap is already being called in the masterpage of the site and I didn't want to call the same library again in my small application production build but I still want to use them during development(because I am only testing it on local and jquery is not called there). TIA
Appreciate your time ready this and hope I got to learn more from you. By the way I created the app using create-react-app but I already 'ejected' it, so its using the webpack 3
Take a look at Webpack externals
You can have two webpack configs, on the dev config you include the package as normal, but for your production config add externals for jquery, so it uses the global one already on the page
The ability you're looking for is named Code splitting
React loadable may be a good option for you as well
I am attempting to publish a small library of react UI components. These components have dependencies: Matarial UI, React Rotuer, etc;
When I build my code I get a warning about exceeding the recommended bundle size. I am at 451Kib. When I analyze my bundle I notice that 96.1% of it is dependencies that have been added to the bundle from node_modules.
Since I am only going to be publishing a handfull of components that are also going to be imported with webpack, is there a way to exclude the dependencies from my bundle and have them packaged in the bundle of any app that uses my components?
I think I need to use code-splitting, or lazy-loading, or something, but I am not sure of the proper way to get started.
Pieces of Advice I can give you:
Use webpack-node-externals to exclude node_modules from bundle. If your code depends on packages that won't be included in the user app - use whitelist to bundle them as well.
Also mark Matarial UI, React Rotuer (and probably react) as peerDependecies in package.json.
I hope this is a reasonable forum for this question.
I have a library of React components that I've developed that I'd like to use in multiple personal projects. When I update/improve that library I'd like it to allow me to update in all projects where it is used.
I'm using Meteor as a build tool, which will prompt me when there is an update available for a dependency it's using, so I assume it'd be an NPM module or something. It is checked in to GitHub and I don't mind if it's public.
What would be the best way to achieve this?
I know two ways:
Publish your module on NPM
Link using npm link
For the first one, your module will be public unless you pay NPM for a private module.
The second one, make your module available locally only (It is used for a development purpose, but it fits your needs).
https://docs.npmjs.com/cli/link
If you have your package published on GitHub, you can simply create dependency by linking to tarball/master. If your path is https://github.com/my-nick/my-package, just add to your dependencies in your project's package.json:
"my-package": "https://github.com/my-nick/my-package/tarball/master"
If you have your package well described (package.json file with name, main and version attributes) it should works after meteor npm install.
Of course it works for Meteor 1.3 and higher only, lower versions don't support npm.
I did not use is personally yet, but an frequently mentioned tool for this purpose is https://lernajs.io/, which is e.g. used by create-react-app.
I want to split my web project into three: front-end, back-end and super-admin.
What is the best way to re-use the components across code bases? Npm packages? That seems hard to maintain:
Open component dev package
Make changes
Push changes
Tag version
Update all projects
Seems complex and prone to errors. Is there a better way?
Depends on if you need to use different versions of the shared components from different projects. If so, you probably need to make a versioned npm package. However, if you just want to share the packages and use the same version everywhere, you have other options. For one, you don't have to actually build and publish an npm packge, you can just use npm link. This will basically create a symlink to your shared code in node_modules of the other projects.
Alternatively, you can do it without any npm package at all, just have the shared components in a separate project (directory) and import them in javascript through an alias, using a bundling system (webpack alias / browserify aliasify).
I want to have a project structure like that:
./app/package.json
./app/src/index.js
./widget1/package.json
./widget1/src/index.js
./widget2/package.json
./widget2/src/index.js
./widget3/package.json
./widget3/src/index.js
As you can guess, this project is like an aggregation of NPM widget subprojects, and the app src folder is the real app, that uses the different widget subprojects.
I want a clear and strict separation between the widgets because my current experience shows me that developers tend to introduce unwanted cyclic dependencies between widgets even if I tell them not too.
In practice, all these widgets will be ReactJS widgets that have for most of them 3 common JS libs: React, JQuery and Lodash. Some will not need these 3 libs, some will need an additional lib like packery, react-slick or react-date-picker All these widgets should also share common test libraries like mocha.
They absolutly need to share the exact same common library versions (because obviously I don't want different versions of React in my project nor to increase my bundle size).
For example,
- widget1 could be a DatePicker widget, that depends on React + Lodash + react-date-picker (npm lib, not mine)
- The app project could depend on React + Redux + Normalizr + all the widgets and their transitive dependencies like react-date-picker
All the widgets will be Presentational components and do not need much more fancy dependencies. Some will only depend on React. Some may have a Redux reducer but as it is plain old JS code, there's no dependency needed.
The number of widgets can be quite big and I don't want to edit 200 package.json files on each library update (however I could eventually use some code to handle that).
When inside widget1/src, it should be forbidden to require code from widget2. If a widget had to be able to depend on another widget, this dependency must be set explicitly in package.json of the client widget.
I should be able to build with Webpack and test all the widgets independently. I should also be able to build and test at once the whole project, including all the subprojects, and having a single aggregated global test and code coverage report.
I don't want it to have a bad developer experience. React and Webpack permits to have Hot code reloading. If I have the real app in my browser and I modify code of a widget, I should be able to see the change live with react-hot-loader and not have to run npm commands nor hit F5.
What I look for is the equivalent of Java Maven's dependencyManagement system where you usually set versions for all your subprojects in parent POM, and versions are somehow inherited to all child projects. All child projects cannot see each others (unless explicit dependency is added), but they can say they depend on a library declared in parent project. All the lib version numbers can be set in the parent project.
Is it possible to do so with NPM and Webpack?
Or at least something close to it?
Thanks
You could put each widget in it's own git repo and install them with NPM via the repo URL. As long as each widget defines the libraries they use in their own NPM package, when they're used in the main project NPM will handle all of the dependencies for you.
Depending on the size of your team you could also sign up for NPM's private packages and host them there https://www.npmjs.com/npm/private-packages
You might want to try https://github.com/n8tz/layer-pack,
as it meets many of the needs mentioned
It allows to:
inherit several npm packages in 1 source tree
manage module inheritance ( drive node & webpack to resolve them well )
put all Webpack conf & profiles in a shared, inheritable and versioned package
etc...
Note that hot reloading with too many inherited packages can be slow.
Alternative is to use precompiled versions of your widgets & externalize theirs deps.