I'm working with the Hot Towel SPA template and I'm trying to add in some data that I want to get from breeze. I have the breeze nuget package installed and the breeze script files are in the scripts folder of the site.
I can reference it by using the actual file name like the following:
define(['durandal/app', '../scripts/breeze.min.js'], function (app, breeze) {
...
});
However, this will break when my site is running in release mode and the script is actually bundled. Plus, it is really ugly and feels like a hack to put the full name in there.
What is the correct way to do this?
By default Durandal loads external libraries via normal script calls not via requirejs. Same is true for HotTowel.
e.g. https://github.com/BlueSpire/Durandal/blob/master/index.html#L31
or if your platform supports it via bundling
https://github.com/johnpapa/PluralsightSpaJumpStartFinal/blob/master/SPAJumpStart/App_Start/BundleConfig.cs#L18
Simply load breeze before requiring main.js and you should be good to go.
Related
I'd like to require a module on a folder, as a plugin. So I want the user to be able to add JavaScript files into an already compiled electron/webpack application and having my application load and execute it. So it would be like a plugin system. I have tried requiring every file inside the plugins/ folder but it turns out that it just gets bundled into bundle.js when compiled, and I want to be able to change it after compiled, like a plugin. How can I accomplish this?
I think what you're looking for is global.require as stated in this similar question.
Note that as it's Node's require, it will cache required module, so modifying a plugin's code will not have effect until you restart your electron application so that it does call global.require again. If that is an issue, you can force-reload a specific module with this (unrecommended) snippet:
delete global.require.cache[global.require.resolve(moduleName)]
We are about to start a new project which should be like a desktop app but still run inside a browser for creating items in a system. After these items are created, an .EXE file on the LOCAL machine must be called to do some code generation. Is this possible if using Angular to develop the application or do we need third party libs for executing local .exe's?
No, this is not possible out of the box. Browsers make very sure that local executables cannot be started. You would have to look for other solutions.
One possible idea, depending on how much effort you want to invest, would be to compile the WebKit engine yourself, i.e., create a binary "wrapper" which runs the browser engine itself. Then you are free to extend it in whatever fashion you need, including adding the possibility to start local .exe's (or if those .exe's are your own applications, you could compile them right into your WebKit wrapper).
Are there any existing solutions for run-time bundling of ES6 modules?
I'm looking to simplify JavaScript code development in a MVC5 web app. We're having issues with large, unwieldy JS files, so I'm hoping to get a module loader system in place. So far, I'm not finding any existing bundle transformers for ES6 or another module loader format. I'd be fine with using TypeScript or nodejs require style. I prefer not to use require.js style, though.
Perhaps there's a good reason this solution doesn't exist already. Maybe the dependency resolution processing is too much for a run-time bundling solution. But, I figure it's worth a shot to ask.
Solutions Considered
Prebuilt Web Client
Ultimately, this is where I want to be, but I need a stop-gap solution for now. I know how to put together a build system for an HTML client using grunt/gulp/webpack. But I don't want to have to tell developers to run webpack -w or something similar during development. Nor do I want to tell them to rebuild a solution for every JS change. They should be able to modify the file, refresh the browser, and see the change.
Directory Structure
This is the route I'll probably end up going with. Basically, this JS codebase consists of jQuery widgets and plain JS (helpers/common functions). So, if I structure the code in this directory structure and include the js dir, it should get me most of the way there:
js (DIR)
app-start.js
helpers (DIR)
widgets (DIR)
Widgets should be fine. Helpers, I can see issues where one function/class depends on another. Though, since a function call should never start with a helper (only a widget), this should work fine, assuming no globals are used (or maybe one global like 'App').
This is coming from the idea of 3rd party libraries being in Script to discourage developers from customizing them. It would encourage them to write extensions to make it easier to take in a new version of either library.
You make a good point about other developers mistaking the durandal libraries for customizable files.
But, you are not required to keep durandal anywhere. The folder structure can be whatever your heart desires. Because durandal does not impose any folder structure.. it only has a recommeneded default setup. There are benifits to following its pattern.
By keeping durandal as part of your application root folder. It keeps all your amd javascript files together in one root folder. This way when you run the durandal optimizer it can scan every subfolder to compress/minify/uglify all your html/css/js into 1 file. This is a nice benifit because its a 1 click build of your entire application.
Also, its a nice seperation because its a good idea to keep your 3rd party non-amd JavaScript libraries in a separate folder structure this way if you use a bundler to compress all your third party libraries into a separate file. The browser can cache your application separate from the third-party libraries. Because the third-party libraries don't change very often, whereas your application will probably be changing frequently.
But durandal's conventions are all completely configurable and you can put durandal in any location you like.
This is a convention that Durandal has decided to use to help keep your customer client code organized in an App folder and away from the 3rd party scripts folder, which gets pretty messy pretty quickly. It does put require.js in the App folder because of the way it relies on require.js and its AMD pattern. require.js is used to help locate all modules and load them as needed (in your App folder).
Is there something specific that you need that this is preventing?
I'm putting together a module I'd like to release, but am a bit stuck on how best to go about packaging it up. In addition to server side javascript, the module will need things like an admin screen, and client side javascript files. That is, it needs to serve out a fixed set of static html/css/js files. (I may have the node-static module as a dependency)
I'm curious what is the best way to handle this. I'd like to make this simple to install and integrate into apps, without forcing the user to dig through a long README. Basically they should be able to NPM the module, then add a line or two of code in the relevant place, and have it "just work". I don't want them to have to download other stuff, tell the module where to find the static files, etc.
Also, I'd like to make sure it can be included in both simple apps (i.e. one step from the standard "hello world") as well as complex apps using frameworks etc like Express, without undue hassle.
Is this possible, or is this beyond the scope of what the module system is designed to handle?
Once your package in installed with npm install mypackage -g you can use __dirname inside your executable to find the directory it's running in.
Likely /usr/local/lib/node_modules/mypackage/bin/mypackage
With your assets in /usr/local/lib/node_modules/mypackage/assets
so __dirname + '../assets' + myasset should correctly find your asset