I have third-party-module-b that uses third_party_module_a global and have
require('third-party-module-a');
in entry point.
The problem is third-party-module-a follows UMD pattern and does not define third_party_module_a global if it detects modular environment.
I'm looking for Browserify transform to fix that.
The transform should essentially replace require (like Webpack expose-loader):
(typeof ... ? window : global).third_party_module_a = require('third-party-module-a');
Or append require to the top of every module (like Webpack ProvidePlugin):
var third_party_module_a = require('third-party-module-a');
Is there such Browserify transform?
Notice that exposify transform does exactly the opposite thing and doesn't seem to be helpful here, despite the name.
Not sure if you've seen this or not but they have a list of transforms available on their github.
https://github.com/substack/node-browserify/wiki/list-of-transforms
Not sure on a specific one but thought this might help if you hadn't seen it
Related
Our team needs to add custom code to the ASM module in order to make SSO login possible in our project, and we realised the AsmComponentsModule doesn't export its declared components. This made it difficult for us to reuse them, since we had to create our own custom module which is a copy of AsmComponentsModule, containing components that are simply extensions of the components declared on it.
This is problematic, since we also had to duplicate HTML and SCSS files. The problem would be even bigger if this module had even more components declared on it.
Is there a better way to do this? Or we should expect a future fix containing the exports array on this module?
PR Fix: https://github.com/SAP/spartacus/pull/15282
Will be released into 4.3.1 and 3.4.7 patches.
Lately I was working on a vue3/vite + ts project and wanted to add eslint and prettier, but I'm getting confused what settings I should use in the eslint file(section "extends") and/or how to spell them. If I look at the official eslint vue homepage, they write the prettier stuff like the not commented out lines(picture below).But if I look at the official eslint-config-typescript page they write it like the commented out lines(picture below).
And if I google I find both examples in projects. So my question is:
Is there any difference between the writing?
Or do they do the same and it doesn't matter which one I take?
I don't know much about vue3/vite + ts, but I see here 2 moments:
Usage of #. It is likely to be related to webpack (I believe you use vue-cli). It usually means something like that: resolve: {alias: {'#': path.resolve('src')}}, So, # is just an alias for some path in your system, usually root/source folder for your project. You can find the exact path in webpack.config.js.
vue/prettier vs prettier/vue. Just location of the package. You either take prettier bundled with vue or a standalone prettier package that contains some custom/adopted version for vue. They are likely to be pretty much the same, check their package.json files for versions.
Normally all global variables and functions in a JS script in a browser are attributes to Window, if I'm right.
With modules that shouldn't be the case. What determines that global vars and funcs do not become attributes to Window? I haven't found a module keyword.
I've been reading quite a lot about this, but it seems to be so self-evident that I could not find an explanation.
I already using the minify argument when building with dart2js.
I looked at the output and I see that the import 'dart:html causes problems in terms of the output file size (2kb .dart file becomes 182kb .js file). For example it imports SVG package though in my code I never touch any <svg> DOM Elements.
I understand that the compiler doesn't know if I'm going to use svg DOM Elements or not. And I understand that the using of var is one of the reasons of that behavior.
But if I will not use any var keywords, the compiler still doesn't have enough 'power' to strip all unused packages and functions.
Is there any directive I can use to forbid the import of certain packages. I mean built-in packages right now. I'm using IntelliJ IDEA and it doesn't allow me to change anything in the Dart default setup.
UPD: Tried to use
import 'dart:html' show querySelector, Element
to import only that method and class, but file size is still 182kb.
The only solution I see for now is to make a few stripped versions of the default 'dart:html' package. The one without WebGL, SVG and some other features.
Because maybe Dart compiler works good, but there is just some methods and classes that I don't use, but the code uses. Like.. the initial package methods checking if some elements are SVG or something like that.
There is a tool for analyzing the output of a dart2js build, especially for references and dependencies. Just tested and gave a better overview in my case.
https://github.com/dart-lang/dump-info-visualizer
hosted :
https://dart-lang.github.io/dump-info-visualizer/
Build with option --dump-info
https://webdev.dartlang.org/tools/dart2js#options
Even when you don't import anything you will get some minimal output size. Dart provides a lot of features like classes with inheritance and mixins (and a lot more) and dart2js output contains code that implements these features.
This is like adding a JS library like jQuery.
Therefore main() {} will already result in an output size of several dozen kb. Adding another line of code probably will only add a few additional bytes.
pub build by default does tree-shaking and minifications, therefore no additional options are required.
In a Rails 3.1 app, one controller needs to have all its views compile whatever Sass stylesheets they might need per request using a set of custom variables. Ideally, the compilation must happen via the asset pipeline so that content-based asset names (ones that include an MD5 hash of the content) are generated. It is important for the solution to use pure Sass capabilities as opposed to resorting to, for example, ERB processing of Sass stylesheets.
From the research I've done here and elsewhere, the following seems like a possible approach:
Set up variable access
Create some type of variable accessor bridge using custom Sass functions, e.g., as described by Konstantin Haase here (gist). This seems pretty easy to do.
Configure all variable access via a Sass partial, e.g., in _base.sass which is the Compass way. The partial can use the custom functions defined above. Also easy.
Capture all asset references
Decorate the asset_path method of the view object. I have this working well.
Resolve references using a custom subclass of Sprockets::Environment. This is also working well.
Force asset recompilation, regardless of file modification times
I have not found a good solution for this yet.
I've seen examples of kicking off Sass processing manually by instantiating a new Sass::Engine and passing custom data that will be available in Sass::Script::Functions::EvaluationContext. The problem with this approach is that I'd have to manage file naming and paths myself and I'd always run the risk of possible deviation from what Sprockets does.
I wasn't able to find any examples of forcing Sprockets processing on a per-request basis, regardless of file mod times, that also allows for custom variable passing.
I'd appreciate comments on the general approach as well as any specific pointers/suggestions on how to best handle (3).
Sim.
It is possible. Look here SASS: Set variable at compile time
I wrote a solution to address it, I'll post soon and push it here, in case you or someone else still need it.
SASS is designed to be pre-compiled to CSS. Having Sprockets do this for every request for a view on a per request basis is not going to perform very well. Every request is going to have to wait for the compilation to be done, and it is not fast (from a serving-pages point of view).
The MD5 generation is within Sprockets, so if you are changing custom variables you are going to have to force a compilation on every single request to make sure that changes are seen because the view is (probably) not going to know.
It sounds as though this is not really in the sweet-spot of the asset-pipeline, and you should look at doing something more optimised for truly dynamic CSS.
Sorry. :-)