I'm trying to share functions across multiple backgrounds scripts in a chrome-extension. This works easily / by design in general as long as you add the scripts to the manifest.json, then a function called from the background.js can call code in another script as long as that other script is loaded first.
HOWEVER, I've tried a few Chrome extension generator templates that have a compilation step with gulp or webpack. (e.g. This one: https://github.com/samuelsimoes/chrome-extension-webpack-boilerplate)
But unfortunately function sharing breaks in the compiled background.js scripts.
I don't know what "magic" in the chrome-extension architecture is broken when compiled code is used.
Any advice/insights on what could be preventing function sharing appreciated.
For details on the implementation e.g. webpack.config etc. please see the boilerplate as that's what I'm working with as well.
Answering my own question after some further research:
The issue appeared to be that webpack compiled each file into a module, necessitating changes to accomodate function sharing between these files.
Rather than adding module.exports statements to each background script, and having to prefix all my function references with the module name, I decided it was easier to rely on webpack (specifically the webpack-concat-plugin) to concat the background files together.
Related
In my vs code extension I want to integrate a preview of a diagram which requires external JS. In a normal web page I can simply use:
<script src='myscript.js'></script>
but this doesn't work in a vscode extension. I tried all possible folders (root, src, out, out/src) to no avail. How can I load my script actually?
Its an older question, still answering so that people can see how to do it.
You have to first expose property inside package.json and use that property as a reference inside your code. Later on when the extension is installed from market-place, you have to ask its users to override the property that you exposed earlier on the .vscode/setting.json.
I'm currently working on an EJS webpage for a single module. In this framework, a set of default scripts are included for all modules, as well as a set of module-specific scripts. I can't change what is included.
I'm having issues getting a certain Highchart to be generated. Long story short, the common scripts included a Highchart library located at the framework's common library path. The module itself included a script to another Highchart library located at the module's local 3rd party library path. The name of these two scripts are different - I'm unable to tell if they are the same version whatsoever.
I'm in the process of troubleshooting but that's not the main point of this question. What I want to know is whether the existence of two different scripts of the same library being included in the same HTML page would cause problems?
It totally depends on the library, and specially, what else is executed between the first and second time the library is being initialized.
Short answer is yes, it is very likely to cause problems.
In IIS and therefore VS, there are virtual directories which allow simplified, virtual, relative referencing in script tags. They are handy. In WebStorm you can get the same effect with Project Directories and then marking your project root as a Resource Root. If you do this, you also get coding assistance in the text editor.
WebStorm also has External Libraries, what is the point of these?
Is this for when you have a link to a CDN in your script tag and you want to get coding assistance? If you already have Project Directories, what is the point of External Libraries?
I've seen this answer and I kind of get the different modes of referencing/inclusion, but I don't get the big picture. What is the core reason for the External Libraries vs the Project Directories?
Is this for when you have a link to a CDN in your script tag and you want to get coding assistance?
Yes, this is the most common case - WebStorm can't use online resources for code assistance, it needs to have the corresponding javascript files available locally. So, if you don't like to pollute your project folder with all these library files, you can have them stored outside of your project and set up as libraries.
What is the core reason for the External Libraries vs the Project Directories?
See above - external libraries allow storing library files in an arbitrary location outside your project folder and still get code completion/highlighting/etc. Please also see the answer you refer to:
Note also that libraries are 'light-weight' as compared to .js files in your project - they are treated read-only, have the inspections turned off. Plus, you can assign documentation URLs to them, enabling external documentation for library code. So, even if you have your library files in your project, it might make sense to add them as libraries
see also this blog post
Today I learned that it is possible to include source maps directly into your minified JavaScript file instead of having them in a separate example.min.map file. I wonder: why would anybody want to do something like that?
The benefit of having source maps is clear to me: one can for example debug errors with the original, non-compressed source files while running the minified files. The benefit of minimization is also clear: the size of source files is greatly reduced, making it quicker for browsers to download.
So why on Earth I would want to include the source maps into the minified file, given that the maps have size even greater than the minified code itself?
I searched around and the only reason I could see that people inline source maps is for use in development. Inlined source maps should not be used in production.
The rational for inlining the source maps with your minified files is that the browser is parsing the exact same JavaScript in development and production. Some minifiers like Closure Compiler do more than 'just' minify the code. Using the advanced options it can also do things like: dead code removal, function inlining, or aggressive variable renaming. This makes the minified code (potentially) functionally different than the source file.
This could still be done by referencing external source map files of course, but some people seem to prefer inlining for their build process.
If you are remote debugging Chrome on an android device, the Chrome debugger cannot just access any file it wants on the device and that includes separate map files. If you include them inline you don't have this issue.
JS bundling tools like Browserify or Webpack will bundle all your .js files input one or several bundles, even in developing mode. So in this case, adding inline source map to generated bundles is the easiest way to help debugging without bringing extra files.
In some situations you might want to include inline sourcemaps into evaluated code. E.g you have a coffeescript input field and you want to enable debbuging the code in coffeescript. There is a stackoverflow question about source maps in evaluated code:
Getting source maps working with evaluated code
You could include #sourceURL in your comments to specify a URL of your eval code and load a map file (see page 8 of SourceMap Spec 3). But it is not always possible to write files to some location.
If you're developing a browser extension, inline-source-map is the only option for debugging since extension itself can't access the sourcemap files -- even if it's possible you have to specify all of your sourcemap files inside the manifest.json(config file for browser extensions).
cheap-module-source-map is much better for a production build.
inline-source-map is used to make quick and dirty builds when testing
The use case (for me) is non-browser environments where source maps are not supported (or very much at all, hence the need for webpack.)
Or another way to put it, webpack without the web.
everyone. I got a dump question , please help.
I create a single page web-app, with marionette , require.js , and the backend is nodejs+mongodb. On the front end , I split the app as one view per file, one model per file and so on. As the app grow big, I got 50+ JavaScript files for this app. Which means, every user hit my site first time will have to down load them with 50+ http requests, this is crazy, isn't it?
So here comes the idea, I want combine all of these files into one, and make it through the google closure compiler, let user's browser relax a bit. But , all dependencies are managed by require.js , so I don't know is it possible to make this real happened.
Any ideas?
RequireJS ships with support to combine/optimize modules into a single file and has support for Closure Compiler. This [optional] optimization step is one of the claimed advantages of using RequireJS and is provided tooling. It can further be paired down with Almond.
RequireJS has an optimization tool that does the following
Combines related scripts together into build layers and minifies them via UglifyJS (the default) or Closure Compiler (an option when using Java).
Optimizes CSS by inlining CSS files referenced by #import and removing comments.