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?
Related
I very recently started programming with react & next.js (previously I was using node.js)
and I made my first application, but on inspecting the page I saw a lot of additional JavaScript (image given below)
here's my directory:
here's my index.js source code:
export default function Home() {
return (
<div>
hello world
</div>
)
}
Here's what I mean by additional JavaScript
Since I've been using node.js I'm not very familiar with all this JavaScript being placed in the code automatically,
could someone please explain what all of this is, where it's coming from and why it's necessary?
next.js or react.js are libraries to create single page applications, you don't need to write html manually now, everything will be generated using javscript. these files are just internal library script files generated by webpack tool in chunks, you might be thinking, why is it so, like we can also store these all scripts into one file, but actually webpack breaks modules into chunks, so that it will only load these files whenever needed for optimization of web performace.
Every time we release a new version of our software which is bundled using Browserify, we are finding that we need to ask our users to clear their cache using the regular methods of CTRL+F5 or diving into the browser settings. It is not ideal when there are a thousand or so users. We are trying to work out a way that we can perhaps get around this. I am open to all sorts of options.
Our project is ReactJS based, so runs in the browser and connects to back end services via a RESTful API. We do track which version is loaded and this is visible from within the console. Using the version number we can compare on two different machines that one user is running the latest version whereas someone else may not be.
The code is bundled into two separate files and I feel that this is where we should be looking.
You need to change the file name on each new release.
A hash of the file is an appropriate thing you could add.
Check out md5ify to add this to your project build.
If you implement this yourself, make sure to also load the correct filename in your index.html file.
Edit:
To automatically load the correct file you need to have a placeholder in your main html.
Then you need a manifest.json file that looks like following:
{
"main.js": "main.[HASH].js"
}
This has to be created automatically after the bundling.
Now you can replace the placeholder with correct asset by doing a lookup in the manifest file.
You either have to write your own scripts for this or use something like gulp together with browserify.
Another solution would be webpack
I've got some ASP.NET that I'm deploying as an Azure cloud service. The javascript files have comments in them that I'd like not to be visible to anyone consuming the JS. I'm taking advantage of ASP.NET bundling and minification:
http://www.asp.net/mvc/overview/performance/bundling-and-minification
This seems to be a nice solution in that it removes all comments during the minifcation process. But I can't count on the fact that the user won't directly point his or her browser directly to the individual, original js files. I'm trying to figorue out how to prevent the user from pulling the js files directly (forcing them to pull only a bundle), in order to prevent viewing comments. Is there a way to implement a black list of files that can't be downloaded? If not, I was thinking of adding a series of random characters to the name of each js file. Lastly, if that doesn't seem like a good idea, I would investigate injecting something into the VS build process to strip comments on publish.
Any thoughts would be welcome.
You can use blockviewhandler in a web.config in the folder your js is in. Explicitly whitelist any files that are OK to download and then block the rest.
There's an example in this question:
Where to put view-specific javascript files in an ASP.NET MVC application?
I think you can modify your deployment process. To your production server upload only the minified js files but to your test/dev server upload everything.
I am using RequireJS and I am creating a own script file for each page. However I also have some components that are included into some of the pages (server side). Should these pages also get their own script file, or should the necessary javascript be in the containing page? Some of the functionality for the included pages are common to many pages.
I think you'd be better off thinking about your javascript as reusable modules rather than page-specific functionality. So, say your page has a search box which initiates an AJAX request, a few date pickers, and a whole bunch of tabs. Each of these should be a module (or if the functionality they provide is complex enough, a few modules). By breaking down your app into small pieces that have very focused aims, you make it easier to test each bit in isolation (automated unit tests) and reuse the functionality elsewhere.
Now as to how to load your javascript modules, there's a point where it makes sense to strategically load stuff based on user needs (ex: core.js is loaded by default but search.js isn't loaded until the user accesses the "search" tab) but you can get pretty far just packaging everything into a single file (require's r.js tool does this for you) and using the same script file (main.js) on every page.
When using a single script file, keep in mind that your js will need to work when the target of it's functionality is not present. jQuery makes this super simple and you almost don't have to think about it - ex:
$('#js-foo').on(...) // <-- this doesn't blow up if '#js-foo' isn't on the page.
I've also seen people set a data-attr on the body tag for the page - e.g. data-page="foo" and key js off of that:
var page = $('body').data('page');
if (page === 'foo'){
component1.setup();
component2.setup();
}
In your case, I would try building everything into a single file using RequireJS / AMD-style modules. Each component would get its own module file (mycomponent.js), your main.js would require() all your modules and init things appropriately, and finally you'd configure your r.js build to package everything into a single file when deploying to / running in production.
If you are interested in exploring this topic more, check out these posts:
Single Entry Point FTW
Single Entry Point Redux
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?