I am fairly new to bundlers and rollup specifically. What is the best way to conditionally hash file names in rollup.config.js when building for production, while at the same time saving the index.html to reference the new .css and .js hashed versions?
I see this in the docs, but I guess I don't know how to conditionally set these options based on dev/prod settings?
output: {
sourcemap: true,
format: 'iife',
name: 'app',
file: 'public/build/bundle.js'
// entryFileNames : 'bundle[hash].js
},
or is using rollup-plugin-hash a better solution?
still not sure what the best practice would be for updating the index.html
(and what does the manifest file option provide?)
You can use a plugin like #rollup/plugin-html to generate a html file that references the hashed filenames.
It is also possible to use the rollup-plugin-manifest to generate a JSON file that will contain these hashed filenames.
This is useful when you can't generate the HTML using rollup for some reason.
Since the Rollup config file is just Javascript, you can include some if statements that return different results based on the dev/prod settings.
const isProduction = process.env.NODE_ENV === 'production';
export default {
output: {
sourcemap: true,
format: 'iife',
name: 'app',
entryFileName: isProduction ? 'bundle[hash].js' : 'public/build/bundle.js',
dir: './',
}
};
Related
I am developing the Argdown VSCode extension. The Argdown parser can be configured using either argdown.config.json files or argdown.config.js files exporting a config object. Using Javascript files is the easiest way to allow users to add custom plugins to the Argdown parser.
If the user tells the parser to use a Javascript file, the file is loaded using import-fresh, (which uses node's require, but deletes the cached version.
Using the Argdown commandline tool (#argdown/cli) this works fine, but in the VSCode extension the module of the config file can not be found. The extension is using absolute file paths to require the config module (e.g. "C:\Users\my-username\projects\my-argdown-project\argdown.config.js"). These paths work with import-fresh outside of the VScode extension.
Is there a security restriction for VSCode extensions that does not allow to require modules with absolute file paths? Or is there some other reason why this does not work?
This was not related to VSCode. The problem was caused by bundling up import-fresh with webpack. I thought that webpack would ignore dynamic imports, but it did not.
I was lucky: Since last month, webpack supports "magic comments" for require (not only for import). So I can use:
require(/* webpackIgnore: true */ file);
You have to activate magic comments support in your webpack config:
module.exports = {
parser: {
javascript: {
commonjsMagicComments: true,
},
},
}
Now the next question is how to add the magic comments to the import-fresh package. For that I used the string-replace-loader:
module.exports = {
module: {
rules: {
{
enforce: "pre",
test: /import-fresh[\/\\]index\.js/,
loader: "string-replace-loader",
options: {
search:
"return parent === undefined ? require(filePath) : parent.require(filePath);",
replace:
"return parent === undefined ? require(/* webpackIgnore: true */ filePath) : parent.require(/* webpackIgnore: true */ filePath);",
},
},
}
}
}
After that, I could load the argdown.config.js files again, even after bundling everything with webpack.
In MODX Revo, TinyMCErte I try to configure the PlugIn via the key tinymcerte.external_config. The config-File has to be valid JSON.
Here is my block, it is ignored.
I want TinyMCE not to convert special characters like german umlaute (öäü) and of cource & should stay & and not &
tinymce.init({
forced_root_block : false,
entity_encoding : "raw"
})
TinyMCE Rich Text Editor (Ver. 1.1.1) is reading the external config file.
the path could be e.g. ../assets/components/tinymcerte/ext-config.json, but it would be advisible to store it in a non web accesible place.
Although this github-entry implies that it reads external config files vom core-path, assets-path and base-path I was not able to get it to work.
the content of the external config file has to be valid JSON:
{
"forced_root_block" : false,
"entity_encoding" : "raw"
}
The keys must be wrapped in "", in contrast to "native" TinyMCE settings (but not sure on this one...)
I did not managed to get the external config file working. I tried an absolute link and a relative. The file did not load anyway.
I edited the file tinymcerte.js in
assets\components\tinymcerte\js\mgr
after this in line 60
tinymce.init(this.cfg);
I put in my configuration before closing the }:
tinymce.init({
selector: "#ta",
schema: 'html5',
element_format : 'xhtml',
forced_root_block : false,
entity_encoding : 'raw'
})
Nevertheless the next update of the extra will destroy this fiddle.
The configuration is connected from the side of php. Therefore, the absolute and relative paths do not work.
Use this kinds of location:
"{base_path}/file.cfg"
"{core_path}/file.cfg"
"{assets_path}/file.cfg"
I want to include /node_modules/es6-shim/es6-shim.min.js into the client side in Sails v0.11.
I've tried including it into the pipeline as such:
var jsFilesToInject = [
// Load sails.io before everything else
'js/dependencies/sails.io.js',
/* INCLUDE NODE MODULE */
'/node_modules/es6-shim/es6-shim.min.js',
// Dependencies like jQuery, or Angular are brought in here
'js/dependencies/**/*.js',
// All of the rest of your client-side js files
// will be injected here in no particular order.
'js/**/*.js',
// Use the "exclude" operator to ignore files
// '!js/ignore/these/files/*.js'
];
Is this possible? I don't really want to use bower or a CDN, I would like to install/update the dependency via npm.
The simplest way to accomplish this would be to leave the pipeline.js file alone and just make a symlink inside of assets/js pointing to the file you want, e.g.:
ln -s ../../node_modules/es6-shim/es6-shim.min.js assets/js/es6-shim.min.js
Next time you run sails lift, Grunt will see the new Javascript file in your assets/js folder and process it with the rest.
If this is for some reason not an option, you'll need to add a new subtask to the tasks/copy.js Grunt task:
dev_es6: {
files: [{
expand: true,
src: ['./node_modules/es6-shim/es6-shim.min.js'],
dest: '.tmp/public/js'
}]
}
and then add that to the compileAssets task in tasks/register/compileAssets:
module.exports = function (grunt) {
grunt.registerTask('compileAssets', [
'clean:dev',
'jst:dev',
'less:dev',
'copy:dev',
'copy:dev_es6', // <-- adding our new subtask
'coffee:dev'
]);
};
After setting up the folder structure for my Gulp project, I was wondering how to do paths in browserify, and found this page: https://github.com/substack/browserify-handbook#organizing-modules. It recommends putting common application parts in a subfolder of node_modules. This appears to be working, it's getting the files, but it's not applying my coffeeify transform, so it's throwing errors because it's trying to interpret them as JS. Any ideas how to fix this? This is my browserify config:
browserify: {
// Enable source maps
debug: true,
// Additional file extentions to make optional
extensions: ['.coffee', '.hbs'],
// A separate bundle will be generated for each
// bundle config in the list below
bundleConfigs: [{
entries: src + '/javascript/app.coffee',
dest: dest,
outputName: 'app.js'
}, {
entries: src + '/javascript/head.coffee',
dest: dest,
outputName: 'head.js'
}]
}
and these are the relevant bits form my package.json.
"browserify": {
"transform": [
"coffeeify",
"hbsfy"
]
}
Transfroms aren't applied to files in node_modules unless they are marked as being global: https://github.com/substack/node-browserify#btransformtr-opts. If you choose to make it global, be warned, the documentation suggests against it:
Use global transforms cautiously and sparingly, since most of the time
an ordinary transform will suffice.
You won't be able to specify the tranform in package.json:
You can also not configure global transforms in a package.json like
you can with ordinary transforms.
The two options are programmatically, by passing {global: true} as options or at the command line with the -g option:
browserify -g coffeeify main.coffee > bundle.js
Obviously it is not that simple. Let's start from the beginning: I'm working on a shared project and yesterday I've been asked to add the plugin mgI18n. I followed the readme file step by step, but when it came down to run the command line to create the table used by the plugin, I got this:
database "" does not exists
I searched it, and I found out that sfConfig::get('app_mgI18nPlugin_connection'); returned an empty value. It was weird, because I've done every step right, setting the value in my app.yml and clearing symfony cache, so I logged sfConfig::getAll(); and found out that the only values for 'app_' stored here were the ones from the file app.yml in the plugin folder of kdDoctrineGuardFacebookConnectPlugin. I've already tried removing that file and clearing the cache, obtaining only to lose these values.
Here is the file contents:
project/apps/frontend/config/app.yml
all:
#other values
facebook:
appId: yyy
secret: yyy
cookie: true
script_lang: fr_FR
perms: email
mgI18nPlugin:
connection: doctrine
cultures_available:
fr: Français
en: English
it: Italiano
de: Deutsch
project/plugins/kdDoctrineGuardFacebookConnectPlugin/config/app.yml
all:
facebook:
appId: xxx
secret: xxx
cookie: true
script_lang: fr_FR
perms: email
and this is what I get when I log sfConfig::getAll(); :
array('app_facebook_appId' => 'xxx',
'app_facebook_secret' => 'xxx',
'app_facebook_cookie' => true,
'app_facebook_script_lang' => 'fr_FR',
'app_facebook_perms' => 'email',
)
Why the values for the main app.yml are not loaded? How do I correct this behaviour?
Thank you all in advance for your help, if you need more specifics I'll glady add them
If I understood you well you are in a command line task context (some sfTask). Symfony tasks by default do not run in application context. In most cases just call your task as
./symfony namespace:name --application=frontend
and you will have your configs.
If it is your own task just add it an option with default value in your configure method:
$this->addOptions(array(
new sfCommandOption('application', null, sfCommandOption::PARAMETER_REQUIRED, 'The application name', 'frontend'),
...
)
Plugin settings are loaded correctly, because plugins are configured per project not application (you enable them in ProjectConfiguration, not generated frontendConfiguration class)