From another question I got a way to dynamically scan source folders using WebPack API, and I've written some code that loads each found class using dynamic imports.
But there's nothing really dynamic here, since source files will be fixed once bundled; so the above code could then be replace with one that statically imports each discovered class.
Is there a way to generate source code during webpack execution and add it to the bundling process?
Whether possible the code should be part of the application, not a separate plugin or anything.
Related
When running a Grails 4 application using 'grails run-app' every javascript file provided by the webserver is starting with the line:
var process = process || {env: {NODE_ENV: "development"}};
This line is not part of the javascript source code and is probably generated by the asset-pipeline plugin. This confuses the hell out of my development environments (both intellij and VSCode) and ruins breakpoint handling.
Does anybody know how i can avoid 'grails run-app' generating this header line?
Some version information:
Grails 4.0.5
asset-pipeline-grails:3.2.4
java-version 11.0.9.
I have generated the 'helloworld' application using 'grails create-app' and run it without modifying anything using 'grails run-app'. Even now every serviced javascript file has the header line.
It turns out you need to overwrite the default asset pipeline with your own pipeline. Your own pipeline will leave out the JsNodeInjectProcessor which is the culprit.
Defining your own pipeline involves the following steps:
modify your build.gradle so all asset-pipeline modules are available at compile time
create MyJsAssetFile based on JsAssertFile from the -core package. From the processors variable, leave out JsNodeInjectProcessor.
create a file main/resources/META-INF/asset-pipeline/asset.specs, leaving out asset.pipeline.JsAssetFile and replacing it by MyJsAssetFile
Doing this will result in javascript files without the header line, and most importantly my Intellij IDE being able to debug my javascript logic embedded in my grails application.
Been struggling with something and I can't find any specific information around this.
I have an application, I'm trying to unit test (Jasmine), but for some reason, the testing project brings down the TS files alongside the generated JS, which is causing some unexpected behaviour:
I figured it has something to do with they way I'm building up the spec runner page, in my case, I wrote a back-end method that loads the necessary JS files from the project I am testing, and adding the references to the JS files to a section on the site, designated for this.
the files are added using their web URL, and not the physical location on the server, for example:
http://directives/Tests.js
Is there a way to stop IIS from bringing down the TS files as well?
AFAIK, in Meteor, when compiling app, all javascript files and all css files will be merged to one file. I think this behavior will slow down app (because user must download all css and javascript that unnecessary for that page). Moreover, this behavior makes our app not dynamic, because maybe some page, we need different css or javascript files.
So my question is: How can we choose custom javascript and custom css for a template ? Does Meteor support this ?
Thanks :)
AFAIK Meteor is not supporting this exactly in that way. So you are left with two workarounds. One would be writing a own extension which helps you in that regard or finding one which already exists. And the other would be putting your special resources somewhere in the /yourMeteorApp/public folder which is excluded from the merge process (see http://docs.meteor.com/#/full/structuringyourapp). And now you could write some template specific logic to load and evaluate JS and CSS resources from there when your template is accessed. Resources in public are available directly on root level - so public/js/my.js would be available under www.example.com/js/my.js.
UPDATE:
This answer is quite old and in modern Meteor apps you should make use of the import logic (and the imports folder) which didn't exist in that way when I originally answered this: https://guide.meteor.com/structure.html#intro-to-import-export
This should be the best way to handle any dynamic JS requirements and strucutre an app by far nowadays.
In practice this has yet to be a problem for me. The combined javascript files are minified and obfuscated. The fact that any "page load" within the UI is done without a server GET makes the UI quite snappy. I have over 20 packages which add up to 2.1MB of js loading when the app cold-starts. Even on iOS it feels fast.
I'm converting an existing project to RequireJS and I'm doing it in steps.
Currently I'm only attempting to conditionally load jQuery 1 or 2 depending on some Modernizr Tests...
However the namespacing portion of the script is located in a template file... while the scripts are currently split up between a batch of files that gets concatenated and minified later and some inline scripts strewn throughout the template files... I hate to just start moving code around and would like to keep most of it in place while I try to get the conditional loading running.. so my question is:
How important is it to adhere to the name-to-file-path lookup algorithm rules in RequireJS?
It says to never define more than one module per file, but I'm unsure why this is.
I think the question says most of it. I have an autogenerated ManualSpecRunner.html file as created by maven / jasmine plug-in and I've got it to put itself into the deployable .war by using:
<jasmineTargetDir>${basedir}/pathForMyWebapp</jasmineTargetDir>
However, all the links to js files within the ManualSpecRunner.html are hard coded file:/// references - this is a bit mental, I want them to just be the relative paths to the files that are also in the webapp i.e.
Currently it gives me this path:
file:///home/username/code/HEAD/pathForMyWebapp/js/yui.js
whereas I need it to have the far more simple
/pathForMyWebapp/js/yui.js
I have tried changing two other variables in the maven script, but neither seems to have the desired effect, neither of these configuration options do what I need, the second having seemingly no effect:
<jsSrcDir>/pathForMyWebapp</jsSrcDir>
nor
<jsTestSrcDir>/pathForMyWebapp</jsTestSrcDir>
I've looked through the documentation but think I must be missing something (also, more notes on various config params listed in https://github.com/searls/jasmine-maven-plugin/blob/master/src/main/java/com/github/searls/jasmine/AbstractJasmineMojo.java are meant to do would be helpful so I can work out if I'm doing it wrong or if it's not possible!)
Any suggestions?
[p.s. I've changed some of the path names as they've got sensitive info in them, so please ignore their oddness!]
I think I understand the source of your confusion. It looks like you're trying to direct the target of the jasmine-maven-plugin to a directory inside your project's packaged *.war file so that you can run your specs against the code after it's deployed to a server, is that correct?
Unfortunately, the plugin wasn't designed with that use in mind. The jasmineTargetDir directory is usually left at its default value of target/jasmine and wasn't intended to be bundled with your application (it's analogous to the target/surefire-reports generated by maven-surefire-plugin for Java unit tests). So the reason that the script tags in ManualSpecRunner.html point to invalid locations is because that file is generated in order to be run from the local filesystem in a browser from the workstation that's building the project (to facilitate TDD).
All of that to say, if I'm reading your intention right, I think it'd be a cool feature to build a third spec runner that could be deployed with the app and executed remotely. (Especially if the project's Jasmine specs are functional/integration as opposed to isolated unit tests.) Unfortunately that's not something the project does yet.
I'm afraid that for now, if you needed to bundle the jasmine tests and execute them on the deployed server, you would need to copy ManualSpecRunner.html and jasmine into your src/main/webapp, fix the script tag references, and then manually maintain it as files are added and removed.
Make sense?