We Keep Coding

Do devDependencies affect bundle size?

I looked hard, and couldn't find a straight answer to this question.
Do the packages I add as devDependencies actually end up in the production bundle JS file and thus affect its size? Or is it only the dependencies that go into the bundle?

No it will not affect your bundle size because those package are only using in development mode. Let's take an example package like typescript
devDependencies: {
"typescript": "~3.2.5"
}
So I only need to have typescript compier, linting just in dev mode. And I'm not actually import typescript in my project because it's only use for dev mode. So if you are using webpack and you wont import typescript anywhere then in your project webpack will you tree shaking to eliminate code that don't need for production build so the bundle will not affect.

The answer is not that easy as might look. Here is clarification: https://github.com/webpack/webpack/issues/520#issuecomment-174011824
And adding relevant snippet here:
A browser app built by webpack has no runtime node dependencies, and thus all frontend dependencies should be listed as devDependencies. The dependencies vs devDependencies naming convention stems historically from node being a server side package manager, which was abused into a frontend package manager, and this is why the fields have names that are counter-intutive when applied to frontend dev, and is why every project ever is getting this wrong. It is as far as I can tell harmless to list frontend dependencies under dependencies, but it is wrong.
I hope this answers your question.

How to "hide" ommit Babel/Webpack/Plugins configuration files?

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.

is it ok to have more than one package.json in a project?

Is it ok to have more than one package.json in a project? I'm working in a .NET MVC solution and it has a package.json at the root level. I need to integrate Jasmine/Karma into the solution and this is my first time doing this type of integration. I found a sample project for Jasmine/Karma on the web and I was able to get this running locally. This project has it's own package.json.
It seems like it would be useful to maintain the package.json file for the sample Jasmine/Karma sample project separately from the package.json at the root level of the solution to provide more flexibility and to allow the same properties to be used differently based on context.
Would this be valid or generally considered an ok practice? Or do I need to figure out how to merge the contents of package.json from the sample project into the package.json at the root level of the .NET MVC solution?

In terms of keeping things simple, it is easier to only have to maintain a single package.json file, but there is nothing inherently wrong with multiple package.json files within a repo. Some companies do use mono-repos, for which it would make total sense to have multiple package.json files.
Multiple package.json files give you a lot of flexibility to run different/incompatible versions of dependencies. As a practical example, on one of the projects that I work on we have 2 package.json files, one for the main application code and then another one for our BDD tests. We use chimp for our BDD tests and had issues with running that on the latest node version, whereas we don't want to keep the rest of the app from upgrading just because of this. We also found that the single package.json file got very messy when it was combined at first.

I would say its typically bad practice to have more than one package.json. I would only expect to have to npm install once, and having to deal with two sets of dependency management could lead to issues down the line.

transpile services module angular 2

I have a common module in an angular 2 application. This is how the project is structured:
main
--app
/common
--config
//.ts configs for modules
--services
//angular services
--models
--store
//ngrx store
/component1
/component2
app.module.ts
main.ts
--js
//systemjs dependencies
Gruntfile.js
package.json
tconfig.json
The project is configured to transpile to bundle.js and works as expected. However, now I want to bundle out the contents of common folder and package it in isolation. Such that, I can just load its dependency using system js, and then include it is app.module.ts to use in components.
I need help in getting started, is it some gruntfile/tsconfig changes that I need to make? Or would I have to create a separate package.json/index.ts to transpile .ts dependencies?

The feature I believe you are looking for is the Bundle Arithmetic feature of the systemjs-builder. It is built into SystemJS and works very well.
However, it will mean using SystemJS to bundle your app instead of a grunt.
This has many advantages and actually simplifies many scenarios, like your specific use case, but it may take you a little while to get everything set up.
TypeScript does not support splitting bundles at this time.
Splitting your app into multiple npm packages is not necessary and will introduce significant complexity into development process if your application is small.

When it comes to using react with yeoman

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!