I'm new the world of automating/testing/bunding with JS and I've got parcel setup for the most part but I noticed that when it builds files, it does not actually save them with the .min.js part in the file name. I'm wondering if theres a way to do this without having to rename the build file manually.
I'm also trying to find a way to have parcel go through the original source files(the ones that you work on) and lint and beautify them for me
Here's what my package.json looks like
{
"name": "lpac",
"version": "1.3.1",
"description": "",
"dependencies": {},
"devDependencies": {
"parcel": "^2.0.0-rc.0"
},
"scripts": {
"watch": "parcel watch --no-hmr",
"build": "parcel build"
},
"targets": {
"lite-maps": {
"source": ["./path/file1.js", "./path/file2.js", "./path/file3.js"],
"distDir": "./path/build/"
}
},
"browserslist": "> 0.5%, last 2 versions, not dead",
"outputFormat" : "global",
}
I checked out the docs but I couldn't find anything on linting or beautifying with parcel. How can i go about doing that? If you have tutorial links to doing so please also share because resources/tutorials seem scarce for anything other than the basic watching and building files
Unfortunately, there is no out-of-the-box setting that can cause parcel javascript output look like [fileName].[hash].min.js instead of [fileName].[hash].js. The .min.js extension is just a convention to keep output files distinct from source files, though - it has no effect at runtime - and the fact that parcel does automatic content hashing makes it easy enough to tell this. And even though they don't have a .min.js extension, these output files are definitely still minified and optimized by default.
However, if you really, really want this anyways, it's relatively simple to write a Namer plugin for parcel that adds .min.js to all javascript output:
Here's the code:
import { Namer } from "#parcel/plugin";
import path from "path";
export default new Namer({
name({ bundle }) {
if (bundle.type === "js") {
const filePath = bundle.getMainEntry()?.filePath;
if (filePath) {
let baseNameWithoutExtension = path.basename(filePath, path.extname(filePath));
// See: https://parceljs.org/plugin-system/namer/#content-hashing
if (!bundle.needsStableName) {
baseNameWithoutExtension += "." + bundle.hashReference;
}
return `${baseNameWithoutExtension}.min.js`;
}
}
// Returning null means parcel will keep the name of non-js bundles the same.
return null;
},
});
Then, supposing the above code was published in a package called parcel-namer-js-min, you would add it to your parcel pipeline with this .parcelrc:
{
"extends": "#parcel/config-default",
"namers": ["parcel-namer-js-min", "..."]
}
Here is an example repo where this is working.
The answer to your second question (is there "a way to have parcel go through the original source files(the ones that you work on) and lint and beautify them for me") is unfortunately, no.
However, parcel can work well side-by-side with other command line tools that do this do this. For example, I have most of my projects set up with a format command in the package.json, that looks like this:
{
...
"scripts": {
...
"format": "prettier --write src/**/* -u --no-error-on-unmatched-pattern"
}
...
{
You can easily make that command automatically run for git commits and pushes with husky.
Related
I want to create RSS script using Next.js.
So I put up a script in a subfolder inside the root folder scripts/ & named it build-rss.js
next.config.js
module.exports = {
webpack: (config, options) => {
config.module.rules.push({
test: /\.svg$/,
issuer: { and: [/\.(js|ts|md)x?$/] },
use: [
{
loader: '#svgr/webpack',
options: {
prettier: false,
svgo: true,
svgoConfig: { plugins: [{ removeViewBox: false }] },
titleProp: true,
},
},
],
})
if (!options.dev && options.isServer) {
const originalEntry = config.entry
config.entry = async () => {
const entries = { ...(await originalEntry()) }
entries['./scripts/build-rss'] = './scripts/build-rss.js'
return entries
}
}
if (!options.isServer) {
config.resolve.fallback.fs = false
}
return config
},
}
When I try to run my script npm run build:development which in package.json represents:
"scripts": {
"clean": "rimraf .next",
"dev": "next dev",
"export": "next export",
"start": "next start",
"lint": "next lint",
"build:development": "next build && npm run export && npm run rss:development",
"build": "next build && npm run export && npm run rss",
"rss:development": "node ./.next/server/scripts/build-rss.js",
"rss": "node ./.next/serverless/scripts/build-rss.js"
}
It throws an error saying:
Error: Cannot find module '../../webpack-runtime.js'
But I checked. The file does exist.
The blunder is this used to work earlier. Probably few versions ago when my other project used the same combination.
I have made a complete reproduction showcasing the error → https://github.com/deadcoder0904/next-script-rss-error
Just clone it, install it & try the script npm run build:development in the terminal to see the error.
Based on our conversation:
entry: path.join(__dirname, '..', 'path/to/file')
That's what a webpack entry looks like. It can also be an array or an object:
entry: [
path.join(__dirname, '..', 'path/to/file'),
// other entries here
]
Whereas you're already getting the whole webpack config:
webpack: (config, options)
So doing:
const originalEntry = config.entry
config.entry = async () => {
const entries = { ...(await originalEntry()) }
entries['./scripts/build-rss'] = './scripts/build-rss.js'
return entries
}
Makes no sense to me if you can just do:
config.entry.push('./scripts/build-rss')
// config.entry['./scripts/build-rss'] = './scripts/build-rss.js'
Unless I miss something with how nextjs is loading the webpack config.
Even then I'd suggest that you use path.join in order to ensure it's loaded to the correct location, because that relative root will execute from wherever webpack is compiled from.
Along with that in your first project you used nextjs v10 and now you're using nextjs v11, which has an upgrade from webpack 4 to 5, which is a major upgrade. I don't know the details, I can only speculate, but under no conditions should you assume that "because your previous project was working this one should using the same stuff", it won't necessarily (especially not in this case).
The first intuitive thing I thought was that webpack should by default bundle everything to a single output file, unless the configuration for that was changed by nextjs (I don't know). So using a script you added to entries didn't make sense to me, because it wouldn't exist. But you're saying that it does exist so I can only assume that webpack is configured to do code splitting and outputs each entry to a different file. In which case I have no idea. As far as I'm aware in webpack 5 (I don't know about webpack 4) code splitting is disabled in dev and enabled in production so your problem is likely a discrepancy between dev and production.
Perhaps the last thing you can try is to change your !options.dev, because right now you're only adding that script when it's production but you're trying to run the script using development.
If you really just have to get it working you can downgrade your nextjs to the previous version you were using (v10), even though that's not really a solution.
Other than that I'm out of ideas.
Not sure if you are still looking for an answer, but simply changing the webpack entry as follows seems to have fixed the problem.
entries['scripts/build-rss'] = './scripts/build-rss.js';
// instead of entries['./scripts/build-rss']
I had the same Error! I deleted the .next Folder and did an npm run dev, It started to work for me!
I have experimented with adding environment variables to my Gatsby project using .env.development and .env.production files and it's working great.
I would like to have my builds fail if one of the environment variables is missing, however I can't seem to see how to enable this functionality.
I have read through the Gatsby environment variables documentation, but can't seem to see how this would work? is this possible?
I believe it uses dotenv/webpack define plugin under the hood.
I’m sure there are other ways to do this, but with some quick tests, this approach seems to be working well for me.
In your gatsby-config.js file, you can choose to explicitly require the dotenv, so you can use those environment variables in your config.
I added the following, and now the Gatsby build will fail unless the specified environment variables are present.
// Load the environment variables, per
// https://www.gatsbyjs.org/docs/environment-variables/#server-side-nodejs
require('dotenv').config({
path: `.env.${process.env.NODE_ENV}`,
})
function checkEnv(envName) {
if (typeof process.env[envName] === 'undefined' || process.env[envName] === '') {
throw `Missing required environment variables: ${envName}`
}
}
try {
checkEnv('NODE_ENV')
checkEnv('EXAMPLE_MISSING_ENV')
checkEnv('EXAMPLE_API_KEY')
} catch (e) {
throw new Error(e)
}
// The rest of the config file
I could imagine customizing this further, ex. logging a warning for a variable with a fallback versus throwing an error for one that is required by your content sourcing plugin or theme. Hope this is helpful as a starting point!
I couldn't find built-in solution for this on Gatsby neither. You may do it manually, but still not too easy.
First problem: If you wanna load your environment from file while running npm script; it can not be loaded right away. But you may trigger a script file, and it can load this environment variables before your check.
lets say build.sh on root directory of project :
source ./.env.development # this line will set env variables
if [ "$API_KEY" = 927349872349798 ] ; then
npm run build
fi
Another problem rises; some developers might want to run it on windows maybe. So better use famous cross-env package.
npm i cross-env
Then everything is ready, add your secure-build :
"scripts": {
"build": "gatsby build",
"develop": "gatsby develop",
"format": "prettier --write \"**/*.{js,jsx,json,md}\"",
"start": "npm run develop",
"serve": "gatsby serve",
"clean": "gatsby clean",
"test": "echo \"Write tests! -> https://gatsby.dev/unit-testing\" && exit 1",
"secure-build": "cross-env-shell \"./build.sh\""
},
And run it :
npm run secure-build
This solution looks too much for me as we created a build.sh and install a new package. Maybe there is cleaner solution. I am not Gatsby Guru after all.
I added env checking to the onPreInit life cycle hook in gatsby-node.ts:
const envVariablesList = [
"ENV1",
"ENV2",
"ENV3",
];
function envVarChecker(vars: string[]): string | undefined {
return vars.find(
(item) => process.env[item] === undefined || process.env[item] === ""
);
}
export const onPreInit: GatsbyNode["onPreInit"] = ({ actions }) => {
const emptyEnv = envVarChecker(envVariablesList);
if (emptyEnv !== undefined) {
throw new Error(`Env variable: ${emptyEnv} is empty!`);
}
};
It fails build almost at the very beginning (during pre-bootstrap phase) if any of the declared variables is missing
I have installed Sublime Text 3 and trying to create the build system for TypeScript. Below are the code I am using
{
"cmd": ["tsc","$file"],
"file_regex": "(.*\\.ts?)\\s\\(([0-9]+)\\,([0-9]+)\\)\\:\\s(...*?)$",
"selector": "source.ts",
"windows": {
"cmd": ["tsc.cmd", "$file"]
}
}
{
"cmd": ["tsc", "-d", "-m", "amd", "--sourcemap", "$file"],
"file_regex": "(.*\\.ts?)\\s\\(([0-9]+)\\,([0-9]+)\\)\\:\\s(...*?)$",
"selector": "source.ts",
"osx": {
"path": "/usr/local/bin:/opt/local/bin"
},
"windows": {
"cmd": ["tsc", "-d", "-m", "amd", "--sourcemap", "$file"]
}
}
Getting [WinError 2] The system cannot find the file specified.
I tried both the Build System unable to generate the Corresponding JavaScript file. Can anyone help me on this. Thanks in advance.
For anyone still trying to figure this out, this is all I needed. The thing that really got me was that I needed to use tsc.cmd instead of just tsc. The quiet:true just removes the [Finished in 1.6s] that always shows at the bottom of the output window.
TypeScript converts the file to javascript and then the javascript file has to be run so...
Make sure you've installed node js and node is in your path.
Make sure you've installed TypeScript with npm install -g typescript (the node package manager) and tsc is in your path.
{
"cmd": ["tsc.cmd", "$file_base_name.ts", "&&", "node", "$file_base_name.js"],
"selector": "source.ts, source.tsx",
"quiet": true
}
I have just started looking at browserify and am wondering what is the recommended way to require the min versions of dependencies when building for production and the debug ones when building for development?
For example, I have followed the tutorial here - http://www.sitepoint.com/getting-started-browserify/ and ended up with the following files:
js\main.js
var names = require('./names.js'),
findSuperman = require('./findsuperman.js');
if (findSuperman(names())) {
document.write('We found Superman');
} else {
document.write('No Superman...');
}
js\names.js
module.exports = function () {
return ['Barry Allen', 'Hal Jordan', 'Kara Kent', 'Diana Prince', 'Ray Palmer', 'Oliver Queen', 'Bruce Wayne', 'Wally West', 'John Jones', 'Kyle Rayner', 'Arthur Curry', 'Clark Kent'];
}
js\findsuperman.js
var _ = require('underscore');
module.exports = function (values) {
var foundSuperman = false;
_.find(values, function (name) {
if (name === 'Clark Kent') {
console.log('It\'s Superman!');
foundSuperman = true;
} else {
console.log('... No superman!');
}
});
return foundSuperman;
}
index.html
<!DOCTYPE html>
<html lang="en" xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta charset="utf-8" />
<title>Find Superman</title>
</head>
<body>
<script src="js/findem.js"></script>
</body>
</html>
package.json
{
"name": "FindSuperman",
"version": "0.0.1",
"author": "Patrick Catanzariti",
"description": "Code designed to find the elusive red blue blur",
"dependencies": {
"underscore": "*"
},
"devDependencies": {
"browserify": "*",
"grunt": "*",
"grunt-browserify": "*",
"grunt-contrib-watch": "*"
},
"scripts": {
"grunt": "grunt"
}
}
gruntFile.js
module.exports = function (grunt) {
grunt.loadNpmTasks('grunt-contrib-watch');
grunt.loadNpmTasks('grunt-browserify');
grunt.registerTask('default', ['browserify', 'watch']);
grunt.initConfig({
pkg: grunt.file.readJSON('package.json'),
browserify: {
main: {
options: {
browserifyOptions: {
debug: true
}
},
src: 'js/main.js',
dest: 'js/findem.js'
}
},
watch: {
files: 'js/*',
tasks: ['default']
}
});
}
Running npm run grunt creates js/findem.js, which includes the debug version of the underscore package (and also starts the watcher).
But I would also like to have js/findem-min.js - the min version intended for production and which should include the min version of the underscore package.
And here there are a few things I need to understand. Indeed:
require('underscore') maps to the debug version. There does not seem to be require('underscore-min'). Seems like one has to resort to require('underscore/underscore-min.js'). Am I correct?
How to require different things conditionally depending on the production or development build, but only when browserifying? The final js file (js\findem.js or js\findem-min.js) should require the right thing unconditionally, of course.
Should I also have index-min.html? Does not seem right. So, I should have one index.html which loads either js\findem.js or js\findem-min.js? Since I cannot have both at the same time I need to serve index.html as a dynamic content rather than a static file. Something like a jade template with the name of the js file being either js\findem.js or js\findem-min.js depending on the startup parameters (NODE_ENV=development comes to mind). Am I correct?
I would like to know whether I understand correctly the items 1 and 3, but I do not have an answer for item 2. What is the recommended way (the best practice, if you please) to do it? I might have gotten items 1 and 3 wrong as well, so please, correct me if I am wrong there.
I haven't used browserify in years. Most people use Webpack now. That said, the parameters passed to Browserify from grunt will control the output. A "run" command typically maps to debug. There will be a separate command to build production files.
For #1, you'll only ever want to write require('underscore'). It's up to the module bundler (browserify/webpack/etc) to rewrite/handle that. Include .js in your requires if you're referencing a specific file. Do not include it if you're referencing a module from outside of your project, such as underscore.
For #2, Browserify has pretty bad documentation. Since Webpack works in mostly the same way here, reading their resolve documentation might help you figure this out. https://webpack.github.io/docs/resolving.html
For #3, that's correct. The HTML needs to reference different .js files depending on if you're in prod/debug. You can hardcode it with two files if you want static output. But in most cases, yes, you typically pick an env variable. Other cases might be serving legacy .js files for old browsers, etc.
Good luck (and switch to webpack :)
I have two projects under a solution, one is my main web project, say MyProject and the other serves for testing purposes, say MyProject.Tests.
Solution
MyProject
MyProject.Tests
I want to have my JavaScript headless tests running to the second one.
On the first project, all the javascript files are under the Scripts directory, like so:
Scripts/
Common.js
Libs/
jquery/
jquery.js
requirejs/
require.js
At the test project, I have my chutzpah.json file on root.
MyProject.Tests
chutzpah.json
Tests/
Specs/
spec.js
The file has this configuration:
{
"Framework": "jasmine",
"TestHarnessReferenceMode": "AMD",
"TestHarnessLocationMode": "SettingsFileAdjacent",
"Tests": [ { "Path": "Tests/Specs" } ],
"AMDBasePath": "../MyProject/Scripts",
"CodeCoverageExcludes": ["*Common.js"],
"References": [
{ "Path": "../MyProject/Scripts/Libs/requirejs/require.js" },
{ "Path": "../MyProject/Scripts/Common.js" }
]
}
But when I try to run the spec file I get an error.
Spec file:
define(["jquery"], function ($) {
//code here. Doesn't matter, the error is because of the jquery module
});
The error, is this:
Error: Error opening C:/Users/g.dyrrahitis/Documents/Visual Studio 2013/Projects/MySolution/MyProject.Tests/Scripts/Libs/jquery/jquery.js: The system cannot find the path specified.
The thing is that chutzpah tries to find my jquery module at the test project rather the main project, where it resides.
Why I'm getting this kind of behavior and how can I solve this please? I've been trying for hours to tackle this with no luck so far.
Note
*The names MySolution, MyProject, MyProject.Tests are used for clarity, rather than using the real names.
I've found it, the chutzpah file hadn't the right configuration options (as expected) for the test harness directory.
I needed the TestHarnessDirectory and TestHarnessLocationMode options to explicitly instruct it to look at my main project directory.
This now is the correct one:
{
"TestHarnessDirectory": "../MyProject",
"TestHarnessLocationMode": "Custom",
"TestHarnessReferenceMode": "AMD",
"Framework": "jasmine",
"Tests": [ { "Path": "JavaScript/Specs" } ],
"AMDBasePath": "../MyProject/Scripts",
"CodeCoverageExcludes": [ "*Common.js" ],
"References": [
{ "Path": "../MyProject/Scripts/Libs/requirejs/require.js" },
{ "Path": "../MyProject/Scripts/Common.js" }
]
}
Just needed to tell chutzpah that the harness location mode is custom, in order to provide a directory for it, which is the root of my main project.
Beware for the right configuration paths then, you may end up struggling for hours like me to find a solution. And read the documentation thoroughly (which I hadn't done).