I'm trying to build an application that have to run on Windows(PC), Android and iOS.
For this, I will use Electron (for Windows) and React Native (for mobile plateforms). Both will be built with React and Redux. This way, I will be able to implement the logic in Redux reducers and middlewares and use them in both projects.
From now, I have done a POC for the Electron app using webpack. The reducers are currently directly in the app code. I want to extract the Redux relative code in a seperate package to allow me using it in a the React Native project.
I can make an npm package for my Redux module containing the reducers and the middlwares but this way, when I will compile my application, webpack will not compile my seperate package, it will use the precompiled version.
So What I want is to be able to make a separate package but still compile it at application compile time (because it is still in developpement and the dev is very closely related to main application dev).
Do I have to do it only with npm or with webpack as well ?
I'm pretty new to the Javascript dev stack.
I think you have different ways to handle that problem.
You can use NPM package. But in code of package, you will store not only original source code, but compiled code too. I mean before publish that package, you'll need to compile it in normal ES5 code.
I think you can use submodule system provided by Git. You should have separate repository with common code of your reducers. And in each project (Electron, RN, etc.), you will have a directory with git submodule. Webpack should compile code in that directory normally without any problems.
UPD:
About submodules you can read nice article here: https://git-scm.com/book/en/v2/Git-Tools-Submodules#Starting-with-Submodules
In few words, in project it will looks like:
cd yourProjectFolder
git submodule add https://github.com/TalAter/awesome-service-workers submoduleDirectoryName
It will clone repository to your project, and create .gitmodules file. Code from submodule will not exists in current project repository. In remote repository it will contain only link to submodule, but on your machine, you will have full code and you will be able to compile it.
Related
The most popular boilerplate for vue/electron usage, seen here: https://github.com/SimulatedGREG/electron-vue
Is outdated, and only uses vue cli2.
The quickest, and easiest way I've found to get Vue and Electron playing nice together is vue electron-builder.
To use, set up a project with Vue CLI3 using
vue create my-project
then CD into that directory, in this case "my-project", and run
vue add electron-builder
This sets up barebones scaffolding that allows vue and electron to play nicely from the get go. You can test your work by launching an unbuilt test version using
npm run electron:serve
and, when you are ready for deployment, may use
npm run electron:build
to build. This vastly simplifies the process, seen elsewhere, of dealing with a giant over engineered boilerplate or trying to write out relative pathing so your builds and dev environments both work identically.
This repository contains the starter template for using vue-next with the latest electron.
I started to learn electron & vue by the great project electron-vue. This project is also inspired from it.
https://github.com/ci010/electron-vue-next
As per the official website, the correct way to save electron files is:
npm install electron --save-dev
Electron is actually required for running the app (quite literally: require()) and this goes against the top voted answer here. So why do we make this exception, if this is even one?
The fact that you require a package is irrelevant to whether it should be considered a dependency or a devDependency (in the npm sense). E.g. many projects use webpack API (i.e. const webpack = require('webpack')) but list it as a devDependency.
The reason is also explained in the post you link to: when you publish your package, if the consumer project needs other packages to use yours, then these must be listed as dependencies.
If your package uses some modules only for build, test, or bundles them into a dist file (i.e. what will be used by the consumer project), then those modules should not be mentioned in dependencies. We still list them in devDependencies for development.
Now in the case of an electron app, there is little chance you will consume your app as a node module of a consumer project, therefore the above convention is not really relevant.
Furthermore, we fall in the case where the electron package is bundled as part of the built output. There is no need for your user to get electron from npm to use your built app. Therefore it matches well the definition of a devDependency.
That being said, IIRC some electron packagers bundle your dependencies into the built app, so you still need some rigour in filling this list.
Cause those binary won't being used when you actually packaging into installer. Most of installer / packager for electron will build package with electron binaries, instead of using dependencies.
I am writing a javascript library that is npm linked to my meteor app. I didn't yet publish the library to npm so it is only local.
Now my problem is, that I want to debug inside the library while using it in my meteor app.
I can debug the meteor app components and using a sourcemap and a standalone html test page also the library itself. But as soon as I use import Library from 'library' in meteor it minifies, uglifies and mangles it.
Is there a way to tell either meteor's build system or my browser to use the library's source map?
Thanks in advance
You can try removing the Meteor minifier package until you need it again:
meteor remove standard-minifier-js
I would like to get an explanation about the way npm modules getting build on install, I'll give an example:
When I'm taking a look on the material-ui npm module sources on GitHub, There's sources but there's no built files, when I take a look on my project node_modules/material-ui directory I can see that the directory contain only the built files (es5, uglify).
I'm trying to understand how that magic happens? I see that there's build script inside the package.json but there's nothing that tell npm to run it on install, what am I missing?
Thanks
Usually modules don't get built on the client's machine, because that would take additional time and might fail because they are using an older version of Node.js that doesn't support the build tools, and of course the build tools would need to be installed as well, which would make the process even longer. Instead you build it before publishing. What is on GitHub is different from what is actually published to the npm registry. Most modules don't check in the built sources into GitHub (although some people prefer to).
Presumably material-ui does this process manually and just publishes the built sources, as seen in Unpkg - material-ui.
Some other packages like redux use a prepublish hook, which builds the necessary sources just before it gets published when running npm publish (Redux prepublish hook), which reflects the published package as you can see in Unpkg - Redux. It's pretty close to the original source on GitHub but only contains the relevant files, including built files that are in its .gitignore file. Because a lot of files are unnecessary to be published (e.g. the test directory, rollup.config.js etc.) and would only take up space on the client, you can specify files in package.json to only publish the listed files (Redux files).
You just happened to have picked a quite confusing package with material-ui when it comes to publishing, whereas redux is a lot easier to understand.
I am exploring AngularJS tutorial project and found it has node_modules directory inside, which size if 60 megabytes.
Does simple clientside javascript project really need so huge corpus of unknown data?
I tried to delete this directory and project still works. I suspect it somehow relates with node.js and it's npm but how? Suppose I need to run my project on some conventional web server (not node.js), then how to know, which files/directories are unneeded?
Many javascript libraries require to use bower to install them. If I use bower, does this mean I need to keep node_modules?
The node_modules directory is only for build tools.
The package.json file in the app root defines what libraries will be installed into node_modules when you run npm install.
Very often with an angular app, on your dev machine or on a build server, you use other Javascript libraries from npm (a node.js package manager) to build your angular app. Tasks can be concatenating resources, using CSS preprocessors like LESS or SASS, minification, replacing of values, etc. etc. The most common tools for managing and running these tasks are called grunt and gulp, which are installed through npm as well.
When you deploy your app, you only distribute the resulting build, not any of the source files or build tools.
It is of course possible to write an AngularJS app without building anything.
edit from comments: When you dive into Angular more, there are more advanced techniques of using libraries installed by npm even in the client app, you then selectively choose the ones you need, not the whole 50MB+ thing. I'd recommend staying with the basic approaches until you get a good grasp on them though.
NPM is the node package manager, which installs packages locally into a project, specifically, into the node_modules folder. From there the package code can be included into a project, yes, can is the important word there.
The browser has no way to include modules in code (yet), so you need to use a library that can expose node's commonJS style modules. Browserify and Webpack are two popular methods of doing so.
Angular complicates this by introducing its own module system, which more closely resembles AMD-style modules. There are ways around this, so that you can use node-style modules, maybe your project uses those.
Using npm for managing dependencies is a great idea, its a fantastic package manager. It is likely in your case though that the project is only built using node and that the node_modules folder contains dependencies only related to the build.