We Keep Coding

Can't get CSS to load when I run npx webpack

I am working through the Odin Project and am stuck on the first lesson where we must build a webapp using webpack. I followed the tutorials here and hereon webpack's website, and I was able to get them to work. However, when I try to set up my own files to build my own project, I can't get CSS to load or a function in my index.js file.
I have the same directory style set up, and have even tried using the exact same index.js file they use in the tutorial.
I expect to get: a webpage to load that says "hello webpack" in red text.
Instead, I get this error: when I run $npx webpack, it says:
ERROR in ./src/style.css 1:0
Module parse failed: Unexpected token (1:0)
You may need an appropriate loader to handle this file type, currently no loaders are configured to process this file. See https://webpack.js.org/concepts#loaders
> .hello{
| color: red;
| }
# ./src/index.js 1:0-21
Upon googling the error, I found a stack overflow article and I tried renaming my rules array to 'loaders' in my .config file as this article suggests, but I still get the same error.
“You may need an appropriate loader to handle this file type” with Webpack and CSS
Also weird is the fact that some of the code in my index.js file works, and some does not. To elaborate, my console.log and alert works just fine after I run $npx webpack and load the page. However, they function that is supposed to add "hello webpack" to the DOM, does not, as evidence by the fact that nothing shows up at all. The page itself is blank.
My index.js code:
import './style.css';
console.log("console works");
alert("alert works");
function component() {
const element = document.createElement('div');
// Lodash, now imported by this script
element.innerHTML = _.join(['Hello', 'webpack'], ' ');
element.classList.add('hello');
return element;
}
document.body.appendChild(component());
You will notice that it is nearly the exact same as the asset management index.js file from the webpack tutorial. I did this purposely to have as little variance as possible between my stuff and the tutorial.
I don't know if it is too much information, but a link to the whole repo as it currently is set up can be found here

Update:
I re-setup the file from the ground up and noticed that the CSS stopped working when I went out of my way to change the bundle.js link they had in their example to main.js. While I double-checked to make sure that I made the correct corresponding changes to output in my config file, making this change had the sum total outcome of not allowing my CSS to work for some reason.
What this reason is? I have no idea, and would be very interested to learn why this happened if someone has a suggestion
But on the offchance that one of my fellow Odin learners googles this problem, I kept the example's bundle.js instead of changing to main.js as my output script and it worked fine.
I'm going to update my github now so my original github link will likely be out of date going forward.

Going through your GitHub repo commit history, I see that at some point you named your Webpack configuration file weback.config.js instead of webpack.config.js (the p was missing). This was likely the source of the problem, as Webpack couldn't find a loader configuration for the .css file you're importing.

Include JS module/file only in development-mode

How can I conditionally import a module only in development mode (in my case the axios-mock-adapter package). Also the code should not even be present in the production bundle.
Example code I only want to be included during development:
export const mockUpClient = (api: AxiosInstance): void => {
// full api mocking, containing lots and lots of data
}
Now I am importing the module based on the following condition:
if (process.env.NODE_ENV === 'development') {
import("./apiMockAdapter").then((module) => {
module.mockUpClient(api)
})
}
The code is still included in the build, however it is not executed in production mode. How is it possible to completely exlude the code from the production bundle (of course without commenting out the code before every build)?
Update
The above example works fine. Before asking the question, I also imported the file from somewhere else, which led to this behaviour.
The accepted answer explains in detail how webpack will bundle the code & modules.

Basically:
Eject from create-react-app with npm run eject. You may be worried about the maintenance burden but it you look at the create-react-app repo you'll see there are very few meaningful changes in CRA and the upkeep with it is actually higher. If you are insistent on CRA then use craco.
Go to webpack.config.js (or craco.config.js if using craco)
Add an externals field if the app is running in production mode
Should look something like this. In this object add an externals part:
externals: isEnvProduction ? {
'myApiAdapter' : 'window' // or something else global
} : undefined,
This will map import('myApiAdapter') to window in production builds and not include it in the bundle.
That said, webpack should see the dynamic import as a point to break the bundle down into chunks, so it's unclear without seeing your actual code why it is included. Making that file external should bypass any such issues.

How to extract Babel generated code from webpack bundles into a new chunk

I'm working on component-level code splitting, using Webpack 4. This means that a single page could have many entry points loaded.
I've got the entry points being generated dynamically, based on a naming convention. The last issue I'm solving for is de-duping the generated code from Babel.
I'm using class syntax, so Babel adds _classCallCheck, _defineProperties, and _createClass to the specific entry (and even duplicates it across import statements). I had a similar problem to this with the webpack runtime, however that was resolved by using the runtimeChunk option. Is there anything similar for Babel? Ideally, it seems, the Babel helpers would be loaded as a separate chunk, and then passed in as a dependency to the webpack chunk. A sample of the bundle
(window["webpackJsonp"] = window["webpackJsonp"] || []).push([["footer"],{
...
...
},[["./src/Feature/WireFraming/code/scripts/footer.js","runtime"]]]);
might become
(window["webpackJsonp"] = window["webpackJsonp"] || []).push([["footer"],{
...
...
},[["./src/Feature/WireFraming/code/scripts/footer.js","runtime","babel-runtime"]]]);
I looked through the webpack docs, and couldn't seem to find anything. Since babel is a pre-processor, I don't believe that splitChunks takes care of this.
Hoping that someone else has experienced something similar.

Moving from Gulp/Grunt to Webpack for an AngularJs 1.x project

I have a two-year-old AngularJs 1.x project, which is built with Gulp for development and Grunt for production (don't ask me why; I don't know either).
The build process is basically:
Compile all scss files into one css file
Merge all JS files into one JS file. We are not using any import mechanism. Each file is basically one of AngularJs' controller, component, service or filter. Something like this:
angular.module("myApp").controller("myCtrl", function() {//...});
Merge all html templates into one JS file. Each template is hardcoded with $templateCache.
Moving assets like images and fonts into the build folder.
Moving third-party libraries into the build folder.
Now I want to switch to webpack for this project. I want to incrementally modernize this project, but the first step would be just building it with webpack with a similar process like the above. I would like to keep the code base as much the same as possible. I don't want to add import for all the JS files yet. There are too many. I would also like to add a babel-loader.
I have some basic concepts about webpack, but never really customized the configuration myself.
Would anyone please give me some pointers? Like which loaders/plugins would I need, etc.? Thanks!

My process to do such a transition was gradual, I had a similar Grunt configuration.
These are my notes & steps in-order to transition to Webpack stack.
The longest step was to refactor the code so it will use ES6 imports/exports (yeah, I know you have said that it is not a phase that you wanna make, but it is important to avoid hacks).
At the end each file looks like that:
//my-component.js
class MyComponentController { ... }
export const MyComponent = {
bindings: {...},
controller: MyComponentController,
template: `...`
}
//main.js
import {MyComponent} from 'my-component'
angular.module('my-module').component('myComponent', MyComponent);
In order not going over all the files and change them, we renamed all js files and added a suffix of .not_module.js.
Those files were the old untouched files.
We added grunt-webpack as a step to the old build system (based on Grunt).
It processed via Webpack all the new files (those that are without .not_module.js suffix).
That step produced only one bundle that contains all the files there were converted already, that file we have added to concat step.
One by one, each converted file gradually moved from being processed by Grunt tasks to be processed by Webpack.
You can take as a reference that webpack.config.
Good luck.

How can I use Gulp and Browserify for my javascript app?

I am finally trying to bring a modern build system to my app, and I'm hoping someone can help. I think I need a few paradigm shifts.
So this is how my app is structured:
/src
/components
/Base
/App.jsx
/Pages.jsx
/...
/Page1
/Page1Component1.jsx
/Page1Component2.jsx
/...
/Page2
/Page2Component1.jsx
/Page2Component2.jsx
/...
/...
/libs
/bootstrap.js
/jquery.js
/react.js
/...
/scripts
/index.js
/utils.js
/styles
/main.css
/html
/index.html
Right now I have gulp set up to do this:
Make a new folder /dest to put everything
Combine everything in /scripts, name it main.js, put it in dest
Combine everything in /libs, name it libs.js, put it in dest
Combine everything in /components, run it through babel, name it comps.js, put it in dest
Copy the one /html file and one /styles file into dest
Then here is how the app runs:
Open index.html
That page requests main.js
main.js requests libs.js and comps.js
Everything works
But here is the issue I'm running into: A lot of stuff here relies on other stuff being global. index.js waits for comps.js and libs.js to load, then calls ReactDOM.render(<App />...), which means both ReactDOM and App need to be global.
Now I'm trying to add something that needs require(), and I try to use Browserify for it. But Browserify takes the code that needs the require and wraps it up in a way that, I believe, makes nothing global.
I realize that I need to turn my app into actual modules, instead of just a bunch of files that concatenate and call each other. And I know that avoiding global variables will be a good thing in the long run. But I'm having a really hard time figuring out how.
For example, I have >50 React modules. It seems wrong to add module.exports to every single one of those, and then import them all to the main file. Further, some of the things in /lib are libraries that don't export as modules, they're made to be run in the <head> tag, like Google Charts.
So I guess my questions are:
Where should my module exports be, and how do they fit into my gulp tasks? Do I concatenate then export?
How do I deal with libraries that aren't modules?
Is my app really poorly laid out, and I just need to restructure from scratch?
Thanks, and sorry about the rambley question.

First, there's nothing wrong with your file structure.
Second, the best thing you can do is follow the "one module, one file" rule. That does mean adding module.exports or export default to every single file. That's just good JavaScript. But it doesn't mean importing them all into your main file, which brings us to:
Third, think in modularity. Files should require or import precisely what they need and nothing they don't. For example, if your App uses Page1 and Page1 uses Page1Component1, then that's how your imports should work:
App -> Page1 -> Page1Component1
-> Page1Component2
-> Page2 -> Page2Component1
-> ...
This ensure separation of concerns and protects your code from easy-to-trigger errors later on (like those from nested dependency changes). And your build system should generate one file (but you can tackle performance later if needed with chunking and so forth).
And you're correct that in this kind of structure, using Browserify or Webpack will ensure that nothing is global - and that's a good thing (though I will note that you can tell them explicitly to expose components, which is sometimes necessary for libraries).
And that leaves libraries that you don't control that you can't import. This does not apply to Bootstrap, jQuery, or React, which all have require-able modules from NPM. But assuming that you have a library you didn't mention that is not available through NPM, you can still include it globally in your HTML with a script tag and tell Browserify or Webpack to expose it for requiring.