I'm building my very own boilerplate starter kit for React + Redux development and wanted to know if there is a way to hide webpack.config.js and .babelrc files?
For example under the hood the create-react-app also has webpack.config.js and .babelrc files but they are hidden until the npm run eject command. How can I do that in a similar way?
Many thanks in advance!
Yes, Facebook's Create React App does this by adding it as a npm package. You can see the package here: https://github.com/facebook/create-react-app or on NPM here https://www.npmjs.com/package/react-scripts.
Then when you build it runs the build scripts inside of the package. I'd put good thought into forking what they have if you are really going down this path and then pull in their updates in a base branch and play forward your modifications.
Related
I am working on a VueJS web app. One of the modules it uses is a wrapper for a javascript library installed through npm and packaged to integrate into vuejs. It does not quite fit our needs, we need to add some functionality to it, so I want to fork it and edit it.
The repo has two folders: src and dist.
As far as I understand, src is the actual src code while dist is a minified version for distribution. Questions:
If I want to edit it, how do I deal with the contents of /dist ? Do I delete it?
Do components installed through npm use the /src/ version or the /dist/ one?
If I delete /dist, work on the /src code, how do I recreate /dist based on the modified /src files?
Thank you.
Based on your questions, I would suggest you get a bit more familiar into your stack and how to actually build your appication.
Generally speaking the /dist folder contains automatically generated files, which may be uploaded to a webserver of your choice. Since you are using VueJS, you should be able to generate these files by running npm run build.
If I want to edit it, how do I deal with the contents of /dist ? Do I delete it?
As I already mentioned, these files are automatically generated by running npm run build. Therefore everytime you run this command, everything in /dist, will be automatically updated.
Do components installed through npm use the /src/ version or the /dist/ one?
Your working directory is always /src. Dependencies can be used like in any other application (this example uses Axios, which is a http client):
import axios from 'axios';
const httpClient = axios.create({ baseURL: 'https://api.something.com' });
httpClient.get(/* ... */);
If you are a beginner and are not 100% sure about how to use depencencies, I highly encourage you to read this article: An Absolute Beginner's Guide to Using npm
If I delete /dist, work on the /src code, how do I recreate /dist based on the modified /src files?
You do not have to delete anything in /dist. Simply running npm run build automatically will add the latest changes.
Please keep in mind that running npm run build is only relevant for your production environment. For your development environment you always want to use a dev server, which can be started with npm run serve.
I'm having a private typescript module that is a dependency of another major project. This dependency is achieved by having the typescript repository as sub-module and installed using npm to the local sub-folder. The typescript module can compile into JavaScript on its dist folder and by doing so the major module that consumes it can make use of it without issues. But here is my problem, the dist folder isn't committed to the typescript repository.
What should be the workflow to follow in order to consume this typescript module from a JavaScript-only major project? The best I can think at this moment is to instruct someone, or something, to run the $ tsc command before using the major project but it's "annoying" since it isn't a transparent step. If this is a weird approach, what would be a more ideal approach? Thanks everyone.
You have a couple of options.
Assuming you're not planning to have a private npm registry using e.g. Verdaccio you can simply commit the dist folder. This is definitely the simplest option and it's not completely unheard of, I'd probably go with that option.
This solution is actually quite unusual, but it's pretty clever and it works. You could add a postinstall script in package.json of your TypeScript package that would run tsc after installing the package. The downside is that you'd have to add typescript as your dependency, which is not ideal (it should generally be a dev dependency, in which case it wouldn't be installed in the project using the package), but for some it might not be a big deal at all.
Instead of installing the package, you could use npm link and then have a script in your main project that would compile it. You'd have to run it every time something changes in that package, though. You could also append it to your npm start script, so it runs before it, e.g. "start": "npm compile-package && webpack" (assuming your current start script is "start": "webpack"). It doesn't scale very well though.
If your Javascript project uses Babel (and I'd assume so considering you said it's a "major" project) you could change its config so it transpiles Typescript for you using #babel/plugin-transform-typescript, however it can be a bit complicated, IIRC e.g. projects created with create-react-app by default don't recompile the code from node_modules.
There are probably more solutions, but I'd probably go with 1 or 2.
Potential similar question here.
I'd like to build a simple in-browser app that can run without an internet connection.
To develop a Python project, this isn't even a question. You just pip install whatever in your favorite virtual env and run offline all day. Your dependency list is also managed for you locally.
While building a toy project with npm, I can't figure out how to do the above. Parcel seems like a good tool to build, bundle, minify, etc. But in the end, all dependencies still point to a CDN. I understand this is default behavior, but there seems no way to easily pull all dependencies local and run offline.
Not a web dev so if I'm asking the wrong question, that sort of insight is appreciated also.
Edit: I've already built all the functionality I need. I can run successfully from file:// or a simple http server. What I'm trying to do in consolidate all the dependencies locally so as to not depend on a CDN at runtime. It'd be better to not go to each CDN/GitHub repo, manually download JS/CSS dependencies, and then manually link to them from my code. That's the point of using a bundler or similar. Is Electron or another framework really the best way to do this? For my use that feels like a lot of overhead.
You can use npm to install and maintain your dependencies. Lets say you are create your project from start. You will need to do the following steps. Assuming you have npm installed.
mkdir my-project //create project directory
cd my-project // cd into project direcotry
npm init // init npm project inside the directory.
After this you can install javascript packages using npm i package-name
I have two Expo (React Native) apps that share most of their code and are already in production. We are trying to move them to a monorepo directory structure as follows:
lerna.json
package.json
packages/
mobile-1/
app.json
index.js
package.json
mobile-2/
app.json
index.js
package.json
mobile-common/
src/
... actual app code ...
index.js
package.json
The way our setup works is that we export a function that starts the app from mobile-common/index.js and mobile-{1,2}/index.js are supposed to call this function with initialization parameters specific to each of them.
The problem with this setup is that mobile-common makes use of react-native and expo dependencies, which are also required by exp to start the React Native packager which causes certain issues at build time. We tried the following:
Adding mobile-common, expo and react-native to the dependencies in mobile-{1,2}/package.json and doing lerna bootstrap. This allows us to run the packager but mobile apps crash while building because they find duplicate dependencies.
We never got yarn workspaces to work, either.
lerna bootstrap --hoist also did not work.
npm link also produced issues at build time with duplicate dependencies.
We really want to move to this kind of structure because our previous structure didn't easily allow us to run both apps side by side, and it is becoming increasingly necessary.
Thanks for helping us out!
If you want to setup expo with a monorepo you can look at my example here.
Currently the expo packages must remain in the root package.json because of limitations with watchman not resolving symlinks properly.
There are a ton of packages out there that have this all bundled up but I dont like the way they set up the projects and such so I was reading the Reactjs docs on installing with npm and my confusion is:
After installing it using npm install react or adding react to
package.json
Do I add this to the "devDependencies": {} or ...
for the require statement to work, do I need to include requirejs?
Can I just do grunt serv to start everything and auto compile the jsx or do I need to do this? (it seems like that might be answered for me ..... but how can I get it to auto compile the jsx when I run grunt serv)
I ask these questions and state I don't like the existing yo ... commands for this because they don't play nicely with bacbone.js So I was going to set this up my self. if there are any repos out there for yeoman that do this for me please point me to them.
dependencies vs devDependencies: for npm package.json, devDependencies are mainly used for the tooling around working on the project itself: testing tool chain and project building modules, for example. Things you'd often see in there: Mocha, Grunt, etc. So mostly for repo contributors and alike. As a consumer of React, you'd put it in dependencies, which are for modules that your code actually needs in order to work.
require isn't for requirejs. The naming clash is unfortunate. require() is part of CommonJS. Node uses CommonJS. Browserify too. Here, it's assuming that you're using Browserify, or maybe doing server-side React with Node.
I'm not sure what you've set up to use with grunt serve. There's nothing magical that makes it work by default. You do need to do what the link said. The --watch option will look for changes to your files and auto compile the jsx to js.
Hope that helps!