Develop Reference

How to modify a npm package locally and build into create-react-app?

I can see that my node_modules/ag-grid-react/lib (the module I'm trying to build locally) have changed (I put console.log commands in main.js, the entry point of ag-grid-react), but the changes are not propagating to my create-react-app even after restarting npm start and running npm cache clean --force. What a I missing?
I believe the crux of the issue is closer to me not understanding how the create-react-app/npm package/typescript/webpack build system works behind the scenes (as opposed to this being an ag-grid issue), but I am including the whole context of my problem in case it's relevant.
Original problem: I'm using ag-grid-react, and I want to inject a button to add a new column, like the image below:
It didn't seem like any of the exposed component allows me to do this, so I have been exploring two options:
Bring ag-grid into my monorepo and fork/modify it
Inject a component with appendChild by finding the ref of the ag-header-row element and creating another react root.
(1) seems cleaner so I'm trying that. I cloned ag-grid via git subtree to my repo, and I am trying to load it in my create-react-app. Here is what I have done so far:
git sub-tree add ag-grid
npm link the local ag-grid/grid-packages/ag-grid-react to my monorepo node_modules
make a modification to the files in community-modules/react/src
run npm run build in grid-packages/ag-grid-react
run npm start in my create-react-app monorepo
I have figured out that grid-packages/ag-grid-react copies the src from community-modules/react before building, via Gulp, but I can't figure out how to load the new build. Anytime I make a modification to community-modules/react/src and run the above steps, no changes propagate to my create-react-app. It almost feels like something is being cached but I can't figure out where.

docker production code build

When creating production build with docker what is the strategy people uses about compiling and bundling the code.
So outside the docker world, I would create a build (using some sort of npm command) which will create a dist. code (without any source code, uglified and compressed javascript for e.g.) and then I point a web server to the dist folder.
In docker world where would you build the code, Is it in docker image or on host os and just copy the dist folder to the docker image? Basically I do not want the whole npm_modules and all source code files in the docker image/container.
Any idea how to achieve this?
Thanks

It sounds like you're worried about two different, valid, problems:
Ensuring an isolated/reproducible production environment.
Ensuring an isolated/reproducible build environment (for building #1).
You can achieve both with the approach you suggested - have the build steps run as part of your Dockerfile. But this has the disadvantages that you mention - you're left with all of your source/development artifacts at runtime, unless you take explicit steps to remove them all.
Docker introduced multi-stage builds to somewhat alleviate this issue - it effectively allows you to "squash" multiple layers into one. But it doesn't eliminate the problem of needing to explicitly clean up.
So in my experience, the most common solution is indeed to build your artifact externally, and then COPY it into your production image.
That solves problem #1, but not #2. So go one step further - build your Docker image inside a Docker container! CI platforms are increasingly supporting this approach as a first-class concept - see e.g. Circle CI's Docker executor.

In Docker, in general, you want to create an image of your software that contains all that is necessary for your Application to run on any machine. This is what Docker is used for: bind the Application and its dependencies into a single artifact so that it can run everywhere where Docker is installed.
The self-sufficient image is very handy when you use an orchestrator like Docker swarm. The orchestrator can run the container on any machine that is part of the network (i.e. the swarm) by pulling the image and starting a container. If nor the image neither the host contain all that it needs then the container fails.
There are cases where you need to change very easy the files inside the container as it runs, for example in development. In that case you mount a local directory from the host into the container (see volumes); in this way you just modify the files in the host and the modification is propagated immediately inside the container. Even in this case, your image should contain the files needed to run the Application on other machine; using a volume just hides them in the development environment.

Sails.js doesn't work, 'sails' is not recognized

'sails' is not recognized as an internal or external command,
operable program or batch file.
So basically I use Windows 10 and I need Sails up and running. I saw on YT people working with that with no problems. I really wanna use Sails.js because it's amazing but I cannot use it.
I don't know what's wrong. I'm doing everything like they say to do. I've installed it globally through npm and of course, I have Node installed and still, I have that error...
What should I do?

It looks like you are missing the path to the sails script in the PATH environment variable. What you can do is find where your sails have been installed:
dir sails.cmd /s
After you find it, open windows menu and type directly 'env' and then select 'Edit the system environment variables'. In the opened window click on the 'Environment variables...' button and add the path to the 'Path' variable.
However, a more preferable way is to uninstall everything (node included) and use the nvm (Node Version Manager) program to get the node itself. You can find it here:
https://github.com/coreybutler/nvm-windows/releases
Then use it to get the node version you want. It is a very useful tool to quickly change between node versions. After that install sails as usual and you should be good to go.

Why isn't Express using a JavaScript to bootstrap?

I am currently getting my feet wet using Express. To start out, I used express-generator to scaffold a simple app.
While examining the project, I noticed that the npm start command is mapped to a binary (bin/www). Upon further inspection I noticed that this file actually contains code to be executed in Node, hence the #!/usr/bin/env node pragma. For anyone having a deeper understanding of Express/Node the answer may be obvious, but still I am wondering: Why didn't they simply use a .js file to bootstrap the framework. That file could then be run using node www.js, I imagine.

There are probably a few reasons why the script was made an executable
npm scripts can be mapped to execute local JS files in the project or executables on the system.
By mapping npm start to bin/www it is effectively the same as running ./bin/www on the command line with the important distinction that by running it via a npm start, it will also work cross platform (e.g. on systems that ignore the hashbang statement, like Windows), otherwise you would need to run it as node bin/www on those systems.
There's a binary ready to add to startup scripts.

Can't generate webpack-assets.json with webpack-isomorphic-tools

I'm trying to learn React and the whole environment built around it. I do that by trying to construct my own dev-stack.
The problem I can't get across for a very long time is how to serve CSS/Images while not loosing a power of server rendering.
I've read a couple of tutorials and discovered webpack-isomorphic-tools
I've configured them and managed to get an images supported, sass (transformed to css) as well.
However, I came across an issue that my webpack-assets.json file is not generated, instead I see this output. ( I managed to get it generated on a 2nd run of npm start before this commit, but that was definitely not a way to go , but it showed that the plugin works when a file is present.)
$ npm start
> redux-universal-example#0.0.0 start /Users/janvorcak/learning2016
> node src/server/index.js
[webpack-isomorphic-tools] (waiting for the first Webpack build to finish)
[webpack-isomorphic-tools] (waiting for the first Webpack build to finish)
[webpack-isomorphic-tools] (waiting for the first Webpack build to finish)
[webpack-isomorphic-tools] (waiting for the first Webpack build to finish)
I understand the purpose of this file, but I can't really figure out why it's not generated at all.
Is there anything that I'm missing?
Here are the relevant files and a repository
https://github.com/jvorcak/universal-react-kit/tree/sass-loader
(sass-loader branch on my universal-react-kit repository)
configuration -
https://github.com/jvorcak/universal-react-kit/blob/sass-loader/webpack-isomorphic-tools-configuration.js
webpack.config.js -
https://github.com/jvorcak/universal-react-kit/blob/sass-loader/webpack.config.js
entry file when running a server https://github.com/jvorcak/universal-react-kit/blob/sass-loader/src/server/index.js
Could somebody please explain what is going on, I've read documentation, blogs, but I'm missing something here. Thank you.

The reason the assets file is not generated is because you have integrated webpack-dev-server into your server.js.
https://github.com/jvorcak/universal-react-kit/blob/master/src/server/server.js#L81
That's a wrong way to do it because in production you won't need webpack-dev-server and therefore its place is somewhere else.
In your case webpack-dev-server is meant to generate webpack-assets.json and this webpack-dev-server is being run after webpack-isomorphic-tools .server() method calls its callback, but it won't call its callback until it finds webpack-assets.json.
The answer is to run your webpack-dev-server in a separate process (you may want to refer to github.com/erikras/react-redux-universal-hot-example for an example of how to achieve that).
https://github.com/halt-hammerzeit/webpack-isomorphic-tools/issues/47
You may also like my very own boilerplate which can do all the fancy things
https://github.com/halt-hammerzeit/webapp