How does browserify handle circular dependencies? - browserify

I'm considering moving a large browser-based code base over to CommonJS (it's an AngularJS 1.x application written in TypeScript). The application has circular dependencies, so I think RequireJS is out of the question.
How does Browserify handle circular dependencies? Are there different categories of circular dependencies that are/aren't supported? Or any tips for working with circular dependencies with CommonJS/Browserify?

Browserify does not add special treatment to cyclic dependencies and the behavior is inherited from Node.
It goes as shown in Node Modules documentation which I'm integrally quoting it below:
When there are circular require() calls, a module might not have finished executing when it is returned.
Consider this situation:
a.js:
console.log('a starting');
exports.done = false;
const b = require('./b.js');
console.log('in a, b.done = %j', b.done);
exports.done = true;
console.log('a done');
b.js:
console.log('b starting');
exports.done = false;
const a = require('./a.js');
console.log('in b, a.done = %j', a.done);
exports.done = true;
console.log('b done');
main.js:
console.log('main starting');
const a = require('./a.js');
const b = require('./b.js');
console.log('in main, a.done = %j, b.done = %j', a.done, b.done);
When main.js loads a.js, then a.js in turn loads b.js. At that point, b.js tries to load a.js. In order to prevent an infinite loop, an unfinished copy of the a.js exports object is returned to the b.js module. b.js then finishes loading, and its exports object is provided to the a.js module.
By the time main.js has loaded both modules, they're both finished. The output of this program would thus be:
$ node main.js
main starting
a starting
b starting
in b, a.done = false
b done
in a, b.done = true
a done
in main, a.done = true, b.done = true
Careful planning is required to allow cyclic module dependencies to work correctly within an application.

Related

Vue-CLI build number - does it exist and how could it be used in a Vue app itself?

I have a Vue app being built for production deployment using Vue CLI.
I would like to include a typical incrementing build number in the application, so that I and testers can be sure we are testing the correct exact build. I would like to use it in the application in at least two ways a) to display it to a tester, and b) to included it in bug-tracking API calls e.g. to Sentry.io.
Currently I have to look at the hash on the app.XXXX.js and compare that. While this does uniquely identify the build, it's not sequential, is different for the CSS/JS/vendors etc and would be difficult to use in the codebase.
I'm happy to write a build wrapper script which manages the number and injects it into the build if that's what it takes.
The command I'm currently using is e.g.
npx vue-cli-service build --mode staging
I've implemented something using the date and time. It's in a Vue 2 project.
Add this code (or something like it) to the top of the vue.config.js file:
const verMajor = 1;
const verMinor = 0;
const now = new Date();
const padTwo = (val) => (val > 9 ? "" : "0") + val;
const nowMonth = now.getMonth() + 1;
const nowDay = now.getDate();
const verBuildDate = now.getFullYear() + padTwo(nowMonth) + padTwo(nowDay);
const verBuildTime = padTwo(now.getHours()) + padTwo(now.getMinutes()) + padTwo(now.getSeconds());
process.env.VUE_APP_VERSION = `${verMajor}.${verMinor}.${verBuildDate}.${verBuildTime}`;
console.log(`Building version: ${process.env.VUE_APP_VERSION}`);
// ...rest of the config
In the component code, you can do this:
get versionText(): string {
return process.env.VUE_APP_VERSION;
}
But I'm using class-based components so if you're not, I guess this will work instead:
computed: {
versionText: funnction () {
return process.env.VUE_APP_VERSION;
}
}
And in the template:
Ver: {{versionText}}
This results in something like:
Ver: 1.0.20211013.110634
If that looks too long, I'm sure it could be shortened according to your needs - or you could store a number in a file and write some JS in the config file to increment it on each build - or each release build if you check process.env.NODE_ENV === "release".
For further information, see: https://cli.vuejs.org/guide/mode-and-env.html
:o)

redux-observables chain simple epics

From this issues thread > https://github.com/redux-observable/redux-observable/issues/33#issuecomment-342399904
I've extracted this helper:
const forkEpic = (epicFactory, ...actions) => {
const input$ = Observable.of(...actions);
const actions$ = new ActionsObservable(input$);
return epicFactory(actions$);
};
My question is, how to insert Epic dependencies on the epicFactory?
Epic dependencies in the form of https://redux-observable.js.org/docs/recipes/InjectingDependenciesIntoEpics.html
The main idea behind is (as discussesd un the issue) is chaining epics
The injected dependencies are undefined, and as said on this question, passing the dependencies director does not solve the issue. (https://github.com/redux-observable/redux-observable/issues/33#issuecomment-342399904)
Just for the record the answer > https://github.com/redux-observable/redux-observable/issues/33#issuecomment-342786804

Specifying a specific module system when compiling Elm (vs. runtime checks)

Is there an option to let Elm know which module system you're targeting during compile time? E.g. something like a --target flag. I must admit that I haven't dug into elm-make that much.
Currently it seems that it only occurs during runtime:
elm-make/issues/50
src/Pipeline/Generate.hs
For my situation I'm:
Using Electron which defines it's own module object and a global window.
Only using Elm for a portion of the project (See HTML interop).
By default, the compiled output defaults to exposing Elm on module.exports:
if (typeof define === "function" && define['amd'])
{
define([], function() { return Elm; });
return;
}
if (typeof module === "object")
{
module['exports'] = Elm;
return;
}
var globalElm = this['Elm'];
if (typeof globalElm === "undefined")
{
this['Elm'] = Elm;
return;
}
In debug tools:
Instead, I want it to expose it on this/window and not overwrite module.exports with the Elm object.
I was able to hack together a solution that abuses the AMD check:
<script>
window.define = (arr, fn) => {
const Elm = fn();
window.Elm = Elm;
};
window.define.amd = true;
</script>
<script src="build/tronwm.js"></script>
<script>
const node = document.getElementById('elm-render');
const app = window.Elm.TronWM.embed(node);
</script>
This works for now, but curious of alternate solutions if any.
As of 0.18, no there is not. The Elm compiler does not know about details of JS Loaders etc.

usemin revved filenames and requirejs dependencies

I'm running into the following problem with requirejs and usemin:
I want to setup a multipage application, where I dynamically load modules that only contain page specific functionality (e.g. about -> about.js, home -> home.js). I could go ahead and pack everything in a single file, but that just leads to a bigger file size and overhead on functionality that isn't necessary on each site! (e.g. why would I need to load a carousel plugin on a page that doesn't have a carousel!)
I checked out the example https://github.com/requirejs/example-multipage-shim
That is in fact a great way to deal with it, until I bring usemin into the game. After revving the filenames the src path of each script tag is updated, but what about the dependencies?
<script src="scripts/vendor/1cdhj2.require.js"></script>
<script type="text/javascript">
require(['scripts/common'], function (common) {
require(['app'], function(App) {
App.initialize();
});
});
</script>
In that case, require.js got replaced by the revved file 1cdhj2.require.js. Great!
But the required modules "common" and "app" no longer work since common became 4jsh3b.common.js and app became 23jda3.app.js!
What can I do about this? Thanks for your help!
(Also using Yeoman, btw)
It's a tricky problem and I'm sure somebody else fixed in in a more elegant way, but the following works for me.
I might publish this as a grunt plugin once it's a little more robust.
Taken from my Gruntfile:
"regex-replace": {
rjsmodules: { // we'll build on this configuration later, inside the 'userevd-rjsmodules' task
src: ['build/**/*.js'],
actions: []
}
},
grunt.registerTask('userevd-rjsmodules', 'Make sure RequireJS modules are loaded by their revved module name', function() {
// scheduled search n replace actions
var actions = grunt.config("regex-replace").rjsmodules.actions;
// action object
var o = {
search: '',
replace: '', //<%= grunt.filerev.summary["build/js/app/detailsController.js"] %>
flags: 'g'
};
// read the requirejs config and look for optimized modules
var modules = grunt.config("requirejs.compile.options.modules");
var baseDir = grunt.config("requirejs.compile.options.dir");
var i, mod;
for (i in modules) {
mod = modules[i].name;
revvedMod = grunt.filerev.summary[baseDir + "/" + mod + ".js"];
revvedMod = revvedMod.replace('.js', '').replace(baseDir+'/','');
o.name = mod;
o.search = "'"+mod+"'";
// use the moduleid, and the grunt.filerev.summary object to find the revved file on disk
o.replace = "'"+revvedMod+"'";
// update the require(["xxx/yyy"]) declarations by scheduling a search/replace action
actions.push(o);
}
grunt.config.set('regex-replace.rjsmodules.actions', actions);
grunt.log.writeln('%j', grunt.config("regex-replace.rjsmodules"));
grunt.task.run("regex-replace:rjsmodules");
}),
You can also use requirejs' map config to specify a mapping between your original module and your revved one.
Filerev outputs a summary object containing a mapping of all the modules that were versioned and their original names. Use grunt file write feature to write a file in AMD way with the contents being the summary object:
// Default task(s).
grunt.registerTask('default', ['uglify', 'filerev', 'writeSummary']);
grunt.registerTask('writeSummary', 'Writes the summary output of filerev task to a file', function() {
grunt.file.write('filerevSummary.js', 'define([], function(){ return ' + JSON.stringify(grunt.filerev.summary) + '; })');
})
and use this file in your require config so that the new revved modules are used instead of old ones:
require(['../filerevSummary'], function(fileRev) {
var filerevMap = {};
for (var key in fileRev) {
var moduleID = key.split('/').pop().replace('.js', '');
var revvedModule = '../' + fileRev[key].replace('.js', '');
filerevMap[moduleID] = revvedModule;
}
require.config({
map: {
'*': filerevMap
}
});
The filerevMap object that I created above is specific to my folder structure. You can tweak it as per yours. It just loops through the filerev summary and makes sure the keys are modified as per your module names and values as per your folder structure.

How to structure a complex web app with RequireJS

I saw there is somes questions related to mine (like this interesting one), but what I wonders is how to do it correctly, and I couldn't find it via the others questions or the RequireJS documentation.
I'm working on a quite heavy web application that will run in only one html page.
Before RequireJS, I used to do a lot of JS modules with public methods and connecting them via the on event on the Dom READY method, like this :
var DataList = function () {
this.base = arguments[0];
this.onUpdate = function (event) { ... }
}
$(function () {
var dataList = {}; DataList.apply(dataList, [$('#content')]);
$('table.main', dataList.base).on ('update', dataList.onUpdate);
});
With RequireJS, I can easily see that I can split DataList and all others classes like this on individual files, but what about the $(function () {}); part?
Can I still keep it this way, but instead of the DOM ready function of jQuery, I put the events on the main function() of the RequireJS, when my primary libs are loaded?
Or do I have to change the way I create JS "classes", to include a init function maybe, that will be called when I do a, for example :
require(['Datalist'], function(dataList) {
dataList.init($('#content'));
});
What annoys me the most is that since I have only one html file, I'm afraid the require() will have to load a huge list of files, I'd prefer it to load just libs that, them, would load sub libs required to work.
I don't know, the way of thinking with RequireJS lost me a bit :/
How would you do?
"Can I still keep it this way, but instead of the DOM ready function of jQuery, I put the events on the main function() of the RequireJS, when my primary libs are loaded?"
If you separate the functions or 'classes' into modules then you can use the RequireJS domReady function:
require(['module1'], function(module1) {
domReady(function(){
// Some code here ftw
})
});
The benefit here is the domReady function will allow downloading of the modules instantly but won't execute them until your DOM is ready to go.
"Or do I have to change the way I create JS "classes", to include a init function maybe, that will be called when I do a, for example"
You won't need to change the way you interact with your code this way, but you can probably improve it. In your example I would make DataList a module:
define(function(require) {
var $ = require('jquery');
var DataList = function () {
this.base = arguments[0];
};
DataList.prototype.onUpdate = function() {
};
return DataList;
});
require(['data-list'], function(DataList) {
var data = {};
// Call DataList with new and you won't need to set the context with apply
// otherwise it can be used exactly as your example
new DataList(data);
});
"What annoys me the most is that since I have only one html file, I'm afraid the require() will have to load a huge list of files, I'd prefer it to load just libs that, them, would load sub libs required to work."
Make your code as modular as you want/can and then use the optimiser to package it into one JS file.