Is there a way to have a tsconfig sitting in my prod folder to only create sourcemaps if process.env is development? I don't want sourcemaps created during my CI/CD build or pushed to production.
tsconfig was not meant to have stuff like env in the file itself its just a simple json file. To do what you want you should be using your own config for each env aka tsconfig.production.json, tsconfig.development.json
You can then in your build pipeline use the --project/--p command when doing tsc to specify your location. So if you want only prod builds being created in your CI/CD then in your step on executing tsc you can just do tsc -p ./tsconfig.production.json where ./tsconfig.production.json is your path to that file. If you want it to use your env itself most of the CI/CD lets you execute a different script depending on the env so again you just execute this one for prod builds.
Another quick note most people structure their tsconfig files to have a base file which say in this example tsconfig.development.json extends and so does tsconfig.production.json. In the tsconfig.base.json you have all the same main settings so you don't repeat yourself twice, with source maps turned off. Then in the tsconfig.development.json you can extend this file and turn source maps on, to still handle nice debugging when on development.
Anyway i hope this hopes.
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 often want to bundle a Node package for the browser, but I'm very tired of keeping Webpack configs and all the dependencies in every project directory. It creates enormous bloat, when every project needs a fairly small set of loaders: Mainly Babel, CSS/SASS, *SV and HTML|EJS.
So I tried to write a module called 'bundle-module' that can be globally installed and invoked inside a project to produce a version in a local dist subdirectory, which it creates if necessary. I got the module to successfully generate a config file with absolute paths to the inputs and outputs when you pass the desired filenames, like so:
npm install -g wilson428/bundle-module
# cd /path/to/myproj
# assume myproj has an index.js with it's own
# project-specific dependencies in package.json
bundle-module --name=myproj --entry=index.js
I thought this was working, but it turns out that, when using the Webpack API to call the compilation process, it looks for the loaders in the local node_modules, such that I get this error:
EntryModuleNotFoundError: Entry module not found:
Error: Can't resolve 'babel-loader' in '/path/to/myproj'
This is precisely what I don't want--for every project to need it's own copy of babel-loader and every other loader.
So, if I could speak to Webpack in plain language, I would say, "Please, sir or madam, when looking for a loader, please look in the directory from which you were called, not the directory into which you're compiling`.
The bundle-module package has all the correct loaders and other Webpack modules as dependences (also tried devDependencies). I also tried "pre-requiring" babel-loader, which didn't help.
How can I get a globally installed Webpack instance to use it's local dependencies instead of the project's dependencies?
I think I fixed this, but I suspect there's a better solution:
In the generated config file, I had to use absolute paths to the loaders pointing to the installed modules in the bundle-module directory:
loader: path.join(__dirname, '../node_modules/babel-loader/lib/index.js')
(Curiously, even though the package.json in babel-loader points to lib/index.js, naturally, this only seems to work if the complete path is specified.
I'll leave this unanswered just in case anyone has a more obvious, simpler solution!
I am using react-scripts v2 (beta) and I have read the documentation here.
We need to create many environments.
We want to store env file under folder config/env.
We might use javascript file in config/env/staging.js because .env seems to be only for root directory.
We have real environment :
default
development
staging
preproduction
production
We expect the default environment to be a default config under version control in config/env/default.js, it must be the default configuration used when doing npm start
We expect the user to be able to override with a file with no version control. (something like config/env/default.local.js
Basically that can be reduced to two issues :
Is it possible to relocate env location folder?
How can we create and select a new environment on npm start/build?
without ejecting.
Just copy the environment file to .env before starting / building. You can even put .env in .gitignore that way
"start": "cp $ENV .env && react-scripts start"
Then run it:
ENV=config/staging/.env npm start
There are lots of ways of doing what you want without ejecting, since it's all preprocessing (before your app starts / builds).
My understanding is that webpack in dev mode will put all your imported somewhere and then serve your bundle.js to the client. When the code inside bundle.js asks for a css file, the css-loader would have been configured previously to set up the file path for your client to ask the server to load the stylesheet. I want to check this somehow and ensure that my sever has the stylesheet. Is there a way to do this?
When using webpack-dev-server your bundle is loaded into memory, not written to disk. If you run the webpack cli instead it will put your assets into the output directory. You can easily check to see if what you expect to be output is there.
If you have installed webpack locally to your project you can run it from your root dir with:
`node_modules/.bin/webpack --config <path/to/webpack.config.js>`
If webpack.config.js is in the same dir then you don't need the --config flag.
This is what you do when you deploy to production since webpack-dev-server is designed for development only.
We have multiple separate ui modules (separate git projects). We are using npm to download dev dependencies for gulp and then gulp precompiles sass, uglify js, build template cash, runs local lint and tests. This means every module have almost identical package.json and gulpfile.js. Is there a way to re-use those, referencing them and not copy them in every project? Or maybe inheriting settings and configuration from a parent like maven does?
Yes, definitely there is.
On the project I'm working now we have quite the same situation: frontend modules are separated into different repositories and have very similar sets of gulp tasks. So, we've moved those tasks to a gulp-common repo and installed it as a dev dependency via npm:
"devDependencies": {
"gulp-common": "git+ssh://our-repo-url/gulp-common.git"
}
Then, in order to load these gulp tasks, we've modified the gulpfile.js so now it looks like this:
require('require-dir')('build/tasks'); // load specific tasks from the usual place
require('require-dir')('node_modules/gulp-common/build/tasks'); // load common tasks
Meanwhile, in the gulp-common we have a ./build directory with tasks and an index.js file:
module.exports = require('require-dir')('./build');
Cheers!