I have a react applications which is very old and configured manualy. I have used nwb packages for building and publishing the packages. nwb seems to produce lots of vulnerabilities and that's why I would like to remove and replace with some other suitable packages.I have searched and found CRA( create-react-app) but as my existing projects already becomes larger, installing the create-react-app and moving the components might not be a good idea. Does anybody have any recommendations or ideas how to replace nwb to existing react applications.
Related
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)
I'm confused why all the React tutorials I'm using to learn React have me installing libraries through npm rather than importing through CDN's (React, Redux, Material UI, firebase, etc). I thought CDN's were more efficient.
Any guidance on this would be helpful (this is my first time using VS code and installing packages like this, the only other website I've programmed I just imported bootstrap and jquery through CDN and coded in notepad++ :/)
While you can of course use a CDN to import scripts into your application (with, for example a <script> tag) npm is useful in the fact that when you build your React app it will bundle all the required modules together.
This can be advantageous in the fact that your users don't have to download any scripts when your application loads (which can take some users with slower connections a long time) since everything is bundled within your React app. Some applications depend on a lot of dependencies, and forcing every new user to download each script individually can cause speed issues.
At the end of the day, I don't think there is a right or wrong answer as to whether you should use a CDN or NPM, just understand that when you use NPM it bundles the required scripts into your app when you run npm run build instead of the user having to download them when they visit your site.
CDN's will only get you so far. In the industry you're going to be expected to have some experience with npm/yarn. If you keeping going down the frontend rabbit hole, you'll eventually run into things like Webpack and Babble which will help make your Javascript a lot more efficient and backwards compatible. Installing things through npm/yarn will also often offer a lot in terms of providing you with a better development environment (things like react-scripts, eslint, prettier, etc).
In work we have a pretty complicated stack and situation, which could be somehow described as the following schema:
The situation is:
We have an old, poorly maintained PHP/AngularJs project which uses webpack for bundling.
We also have another project ("Some React Project") which contains a few sub-projects, and all of them are bundled into some bundle, which is then bundled with the old angularjs project. The AngularJs project then renders the React components from this bundle using some bridge library.
In addition, we have another modern React project, which is completely isolated and has it's own CI/CD process (it's actually another app).
Now we are going to develop a new module, using react, which should be used in all three projects.
We first thought about maintaining it by publishing it to NPM and for each update, to deploy it in any project using npm install. The problem is that it has SO MUCH OVERHEAD. It is so very hard to test and deploy. It's hard to maintain and since
some of our projects are very old, it's a complete nightmare.
Are there any other options available?
Is it possible to somehow deploy to package artifacts somehwere, and then automatically update it in all the projects?
Have you considered installing directly from another repo ?
Actually the overhead might be to have an auto-updated package. This would mean that you could never introduce a breaking change in that package.
{
"dependencies": {
...,
"common-package": "git+ssh://git#<your_forge_host>/path/to/<repo>.git#<your_tag_or_branch>",
...
},
...
}
Usually when I try a React package from GitHub, I never bother checking the React version that the packages is using. I'm curious now; does it actually matter? Will there be any conflict between dependencies?
Let's say there is a React package, packageA, that is using React v16.8 while my React project is still using version15. It's a huge leap. Will there be an issue whereby packageA is using some advance feature which is not supported by my project? Or will this simply not happen because everything is handled nicely by BabelJS?
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.