Ideally, it should be able to encapsulate the electron-builder and related webpack parts, only two commands are exposed dev: electron / build: electron
But in fact, the electron-react-boilerplate template is too complicated, and did not need so many functions at first, but this template is to pile all the functions at once.
My generation found a repository https://github.com/nateshmbhat/electron-react-ts-starter, but this directly divided them completely, and did not consider the problem of code reuse. . .
Take a look at generator-react-app-electron on npm (https://www.npmjs.com/package/generator-react-app-electron).
This generator produces a non-ejected create-react-app project that is configured to run out-of-the-box with electron and a few other handy features
It provides start and build scripts that have been configured for running and building electron. Without ejecting. It also provides all essential features to develop an electron app (e.g. splash screen, entry points, ..).
Also you could use this template directly without using the generator: https://github.com/neutrinog/react-app-electron-template
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).
I come from a background in Angular, but I wanted to start learning React. I want to make a React front-end for a nodejs Express web service.
In Angular, I could simply build the source code into a static folder with a standard index.html, and it can be deployed on any web server. With React however, every tutorial I see is about running React in its own server using create-react-app and npm start.
I know you can also just use script tags to import the React framework in a static page, but then you can't use JSX syntax, and I would like to. Is it possible to simply build a React project into a static folder with an index.html that can be deployed on any web server?
Yep, you can do what you're describing. If you want to use JSX syntax, you'll need Babel, which transpiles it into standard JavaScript.
You can avoid the complexities of setting it up by using create-react-app to create the app, then running npm build instead of npm start. This will compile everything into a build directory, complete with index.html.
CRA uses its server for development purposes. You don't need CRA for using React of course. But, as your app getting bigger and bigger you will need some more extra tools. For example you want to see your code instantly without refreshing your browser. Here comes the dev server and hot reloading.
CRA uses Webpack behind the scenes. It is a great tool for bundling (obviously) all your files (including css), minifying, uglifying, optimizing your code etc.
For simple code or testing purposes using one file and attaching React and Babel to your file could be enough but for real apps you will need more. Either you will use something like Webpack on your own or you will use CRA and let it do all the extra stuff for you.
I have an existing MVC project built with Yii2 (a PHP framework) which generates and serves HTML pages.
I'd like to write just one complex Component (with 3rd-party modules and a lot of other dependencies) only for a page (generated by Yii2); so it's important to clarify that I don't want to leave all the frontend side to ReactJS and I don't want / can't migrate to a complete frontend app managed by ReactJS.
What's the best way to integrate ReactJS (with its stuff like npm, Webpack, etc)?
Should I write the ReactJS app in a "npm environment", bundle everything and include the "build" static resources into the Yii2-generated page?
For complex scenarios it is better to use "npm stack" to build your assets and create asset bundle to only register files generated by tools like webpack or gulp. Yii tools for compiling and compressing assets works fine for simple cases, but they're very limited when you compare it to tools from npm ecosystem.
You could look how official website of Yii Framework was build: they used yarn and gulp to build frontend assets and one simple bundle to register generated files. The main difference from normal "npm fronted flow" is that they used assets-packagist to install frontend dependencies.
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.