I'm trying to get my head around bundles in MVC 4. From what I've read, you simply point it at a script or bunch of scripts, give it a name, and it'll bundle them up. If you're not in debug it will also minify them.
Sample Code:
bundles.Add(new ScriptBundle("~/bundles/jquery").Include(
"~/Scripts/jquery-{version}.js"));
If it's done dynamically, why does the project have .min.js files for every script? Does the minifying process actually just load .min.js rather than minify it itself?
If you run in debug mode, the .debug.js files are included. If you run in release mode, the .min.js files are included. If the file is not .debug.js or .min.js, it's included in both cases.
In release mode, all the files, are minified and bundled in one file. No matter if they were or not were previously bundled.
I usually have the original, not .min.js or .debug.js files, and let the bundler do all the job of minification.
There is also another important thing you must be aware of: the bundler will reorder the included files according to internal rules. And, if you use wildcards, the files are included alfabetically. This can make fail your scripts if there are dependencies and they are included in the worng order. You can run your site in debug mode to check the order (look at the rendered script tags). If the order is wrong, you can tweak the file names or implement an IBundleOrderer.
This is a very interesting article on bundling.
Related
I have created a Razor Class Library to be able to distribute some global styles and views across projects, but I can't seem to import my .less files from the Razor Class Library.
In my RCL I have:
Styles
-Shared
-layout.less
-variables.less
In the project referencing the RCL I have:
Styles
-main.less
main.less only has:
#import "./Shared/variables.less";
When I run a build via webpack I get errors that it cannot resolve ./Shared/variables.less, but it works fine if I copy the Shared directory from the RCL into the project referencing it.
I have the BuildAction for the RCL .less files set to Content, is there anything I am missing, or is this something that is not possible?
It's some what possible, but not for specifically what you're trying to do here. An RCL is ultimately a DLL, so the only thing you can include in it, is things that can be "compiled" into that. I say compiled with quotes, because static files can be included as embedded resources, so while they're not themselves compiled, they are still literally being embedded into the resulting DLL. With the ManifestEmbeddedFileProvider, the app using your RCL can read from these embedded resources as if they were literally on the filesystem.
However, and importantly, they are not on the the filesystem, which means using things like webpack is a 100% no-go. What you'll need to do is actually do a webpack build as part of the RCL, and then embed the resulting static resources in the RCL. Your app, then, can have its own webpack build for it's own resources, but you won't be able to combine primitives from the RCL with primitives from your app.
You could possibly manually manage the build order and run a powershell script post build (making sure that the correct dll is building first) and interrogate the dll and extract the required files (?) into the correct folders in wwwroot, or wherever, before the webpack build. I think that happens after the projects are built, but I'm not an expert on webpack either and I haven't actually tried this.
Also technically if you want any static or view files to be embedded in the dll you would select "Embedded resource", well that is how I've done it in the past.
I have a Middleman project that includes several Less files. I think Middleman attempts to build the files but fails. I can reproduce this on a a clean install. I just initiate a project, add an empty 'test.less' within the source folder and then either build or run the server -- both fail. I get an error to the tune of: cannot load such file -- less (LoadError)
Is there a way to explicitly ignore these files?
Middleman has support for ignoring files. The docs for this are part of the dynamic pages feature.
In your config.rb you can call ignore "test.less" and this file will be ignored.
You can make this more complex by using globs or regexes e.g. ignore "*.less". See the ignore docs for more detailed information.
So here's a question. I'm new to Sylius, and am working on some simple CSS updates. I have a local copy of Sylius running with the built-in webserver: server:run. I also have a development server on Digital Ocean, which runs an (almost) identical copy of Sylius, aside from the configs of course.
Something strange is happening with my CSS update, however. I made a change to .navbar-brand within web/assets/compiled/backend_backend_4.css.
This change showed up immediately on my local. On the development server, however, when pulling down the change (git), and verifying that it now exists in that file, the change doesn't seem to propegate. It's effects aren't shown, inspecting the stylesheet doesn't show them, and furthermore viewing the css file sourcecode directly in the browser does not show the change. But on the filesystem it's definitely there.
I've tried clearing the cache, to no avail.
I also checked the assetic value in both config_dev.yml files, and verified they are both set to use_controller: true
Even still, I tried dumping assetic, to no avail.
So I'm wondering what's going on. Additionally, I realize that I probably shouldn't edit CSS files within a folder called 'compiled'. I'm sure there's a way to do that using a compiler, but I'm not yet familiar with the process and am just making minor changes and learning about caching so far.
Yes you are right you shouldn't be editing the compiled files.
You should edit the source files, then run gulp
or on my system i have to explicitly run npm run gulp
I've documented the solution that worked for me here. It didn't involve Gulp at all, but instead uses Assetic:
Assets need to be installed as hard copies first (I'm not quite sure
what this does exactly, but it seems like an important step because
it copies a lot of assets to places. Documentation was unhelpful but
it was suggested on Stack Overflow somewhere.):
app/console assets:install web
Assets should be edited in web/bundles/[bundle-here]/css or js. This
is frequently within syliusweb if it has to do with page styles /
layouts.
Hint: These assets are referred to in files such as
src/Sylius/Bundle/Resources/views/Backend/layout.html.twig (see the
opening:
(% stylesheets
tag, or search universally for this tag).
Within this tag, you'll see that stylesheets have an output to the compiled folder, but also list the
bundles where they pull their original css from. You should edit one of the source css files, if you'd like your changes to end up in the destination css.
After editing assets, dump assetic:
php app/console assetic:dump
Note - it is also possible to set an assetic watcher on these assets
(google to find out how, think it's a -w flag somewhere), but this is
said to only work in development mode, as it should.
After dumping assetic, the assets from the source bundles compile into their assets/compiled versions, usually combining multiple stylesheets. You should now see your asset refresh!
I want to set up my HelloWorld intellij-erlang project with all files in the same directory so I can easily switch between IDEA and emacs/vim.
<my-project>/hello.erl
<my-project>/hello.beam
Now, if I configure the output directory to be the same as the source, hello.erl gets emptied as part of the build and the compilation fails.
I assumed it's something to do with copying resources to the output directory, so I've configured intellij-erlang to exclude *.erl from the resources with a !?*.erl pattern, but this does not have any effect, hello.erl still gets emptied before the compilation takes place.
As an experiment, I've also tried using separate src and out directories, and intellij-erlang always copies the *.erl to out irrespective of the resource patterns.
Based on all this, I would conclude that intellij-erlang cannot work with all files in the same directory. Have I missed anything?
Erlang programs should be build on standard OTP directory structure. Build tools like rebar (used by intellij) or erlang.mk build on this conventions. And so should all IDE's.
Intellij does it, just like you notice. And so does Emacs's plugin (that I use and can confirm). I would guess so does Vim's one.
So if you would like to be able to switch easily between your IDE's you should try to keep to this convetion of keeping you source files in src and compiled files in bin (and headers in include).
I started using sass scss stylesheets. These generate *.css files from *.scss files. My question is, which files do you check into version control? Right now I check in both main.scss and the generated main.css. I wonder though if there is a way to just check in the *.scss file and to ensure that the *.css files get generated on deployment.
I prefer to check them in. We deploy to our staging and production environments from git and I prefer not to rely on yet another tool/compilation when deploying to production. This way, its absolutely clear what is being pushed out.
In general, you usually don't need to check generated files into source control. As long as your code generation works consistently, and you use it consistently to update your target .css files, I don't think you would need to put them in source control.
That said, the suggestion to not put generated files into source control is usually intended more for binary files (i.e. libs or executables generated from a build). The main reason for this is that binary files cannot be easily diffed/merged, so if multiple people try to checkin changes to the same binary, you may end up with merging issues that cannot be easily resolved. Since you're dealing with plain text css files, I don't think it's that big of a deal to just put them in source control too, just so you have a backup of the actual target file.
I like to borrow from the conventions used by server side developers when handling compiled front-end code like sass. I keep all of my source separate from compiled code. Here's how I set it up:
Put your source in a src directory, under main/language-name, in this case:
/path-to-my-app/src/main/sass/my-syntactically-awesome-file.scss
Then put tests in an identical test directory (you shouldn't need any tests for sass, though:
/path-to-my-app/src/test/sass/my-syntactically-awesome-test.whatever
Then put your compiled code in a publish-ready directory, like so:
/path-to-my-app/publish/css/my-syntactically-awesome-file.css
Then commit the whole shebang (!)
You can make sure you are always putting your css in the right place like so:
$ cd /path-to-my-app
$ sass --watch src/main/sass/*.scss:publish/css/
Now you're a mother effing programmer, baby!