Electron-Builder is bundling all sorts of files we don't need from Firebase.
For example, we don't use Firestore, but still the firebase/firestore folder is included in our bundle, and inside of that:
/dist
index.esm5.js - 838kb
index.esm2017.js - 767kb
index.node.cjs.js - 1.1mb
index.node.mjs - 1.1mb
index.rn.js - 767kb
So we don't even use Firestore, and on top of that these needless copies are bundled.
How can we prevent this without needing to exclude every individual directory and/or file in Electron-Builder's files?
If it matters, we bundle with Webpack, never import the entire module, never import the compat modules, yet they're all still bundled. And Treeshaking for every other package works as expected.
Related
I'm working on a plugin for Moodle that involves a lot of compiled JavaScript. Because of the complexity of the plugin, I'm writing it in TypeScript and compiling it with Webpack. This is all working fine.
However, Moodle has built-in Grunt tasks to help with JavaScript deployment, including uglifying the code. My compiled code is already minified, so this step isn't necessary. For some reason, putting the compiled code through the uglifier creates errors in the browser that aren't present with the non-uglified version. Because of this, I'm hoping to find some way to override the Grunt task.
The Grunt task is pretty simple; it uses a glob to find all javascript files in the various plugin folders in Moodle. I don't want to modify the top-level Gruntfile so that others can use this plugin without having to touch the core Moodle files. Is there a way I can create a Gruntfile (or some other flag) inside my plugin's directory that signals the parent Gruntfile to ignore my compiled file?
Unfortunately, removing my file from the watched folder is not an option. In development mode, Moodle serves the pre-compiled "src" script, so I need to keep the file there for development purposes (otherwise, I need to manually purge the cache each time I want to load the updated file).
Here's a general overview of what's happening:
Directory structure:
public (main Moodle directory)
Gruntfile.js
local
my-plugin
amd
src
my-webpack-compiled-plugin.js
build
my-webpack-compiled-plugin.min.js
my-webpack-compiled-plugin.js is the file output by Webpack (the file I don't want to be uglified)
The Gruntfile.js contains, amongst other things, this:
amd: {
files: ['**/amd/src/**/*.js'],
tasks: ['amd']
}
The amd task is where the files get uglified.
So I'm hoping to find some way to exclude local/my-plugin/amd/src/my-webpack-compiled-plugin.js from getting to the amd task from within the /local/my-plugin directory to keep my plugin self-contained.
I'm a bit new to Symfony and I'm don't know what to use for my static file management. I have read about Assets component and the Assetics bundle.
I know that Assets just includes the files and Assetics is a bit smarter as it can combine files and compress images. But I already use compass to minify and combine the css files so therefore Assetics is not really required.
Version control so the url of the static files change to by pass browser cache, is done by both.
Assetics is removed from 2.8 or higher, does this mean it is not best practice anymore?
I need to generate urls on three places:
Twig -> Easy to do with both
Controller -> Found only a way to do this with Assets
In css files -> Believe it is with both not possible
Wat would be the best to use in my case, any advise?
Assetic can be seen as a way to easily apply filters and compile your assets. The asset component basically is used to manage URL generation. As you said, both nicely are integrated in Twig via extensions, and controllers via the services.
Our application uses compass too, but Assetic makes sure that the compiling happens at the right moment without the need of compass watch at the commandline.
Think most of your questions are answered on:
http://symfony.com/doc/current/cookbook/assetic/asset_management.html
and
http://symfony.com/doc/current/components/asset/introduction.html
I've been using the RjFrontendBundle to run the front-end CSS/JS build, and also copy other static content into place from Bower/NPM/local sources. It provides a VersionStrategyInterface for the Assets component that creates, and uses unique filenames in production (renaming the files with an embedded hash, via the GulpJS rev-all package). In dev, it uses the normal filename.
Within CSS files, you can still reference CSS/JS, via a url() function, and the pipeline will rename them appropriately in dev and live.
The GulpJS build tool is used to minify and otherwise prepare the plain files. It comes with a setup console command to build the initial gulpfile.js and can also watch and rebuild files, updating the browser as they are changed, which helps with front-end development workflow.
The trend is to use standalone front end tools such as gulp/grunt/sass instead of assetic. The reasons are (probably) as follows:
gulp / grunt are independent from the framework, providing the same workflow for the front end guy no matter what underlying framework is used for the backend.
assetic has a different workflow than most of the modern tools. It assumes that you will write your script/css includes in the templates. Migrating from assetic to gulp could be a pain for large project.
as your project grows, assetic can become kind of slowish... As that happens, you will stop pulling your assets from the controller and start generating them the way gulp or grunt does. In this scenario, gulp and grunt are just better tools.
assetic lacks some important features, such as including processed assets into HTML code (inline). Because of the way assetic works (twig tags), it might be difficult to overcome this.
As for generating the URLs: assets are just files in the filesystem. Write a function or twig extension to generate URLs to those files.
I have a package which includes a file that gets frequently rebuilt. This causes meteor to restart each time that file is edited.
There are ways to get meteor to ignore files within the main app, eg putting inside a .directory but is there a way to do this within a package?
The catch is that I DO need the final file to be included for deployment, so it has to be named - as an asset - and included in the package addFiles.
The only solution I have so far is to host the asset external to the meteor app and load it in via http or something on each cold start, but that's a bit fragile.
As of Meteor v1.5.2.1, there is support for a .meteorignore file. It behaves the same as a .gitignore. Have you tried using it?
You can use them in any directory of your project and are fully integrated with the file watching system.
Is there some specific folder in Meteor file structure which is simply ignored by Meteor? (meteor bundle and meteor deploy etc)
Or better yet: is there a kind of .meteorignore file where we can list files for Meteor to ignore?
There's no such file as .meteorignore yet.
Currently the only reliable way to hide a file from Meteor is to make it hidden (add a dot to the beginning of name). You can hide the whole directory, which is useful if you need specific filenames for things like Grunt tasks.
For example if you create a directory called .hammerTime, then Meteor can't touch this.
Update:
As of Meteor v1.5.2.1, there is support for a .meteorignore file. It works exactly the same as a .gitignore.
As of Meteor v1.5.2.1, there is support for a .meteorignore file. It works exactly the same as a .gitignore.
You can use them in any directory of your project and are fully integrated with the file watching system.
Tl;dr : Is there an equivalent in meteor to .gitignore?
Yes, I am aware of using a leading '.' in the directory name to get meteor to exclude it. But using leading dot is not a solution in this case. Read below to understand.
Longer:
I would like to use Bower.io to install various browser plugins.
Ideally, I run bower in the client subdirectory. Bower does its thing creating the bower_components directory and pulls down the plugin (pick a random jquery plugin for example).
Many plugins include example html, demo css files, etc. to show how to use the plugin.
Unfortunately, Meteor wants to include all that stuff in the application. Which unsurprisingly causes problems.
My current solution is to have bower.io run in the project's parent directory. This is not ideal as I have to copy js/css files over from the bower directory to the meteor client directory. (yes, I could use soft links but then the files would be missing when pushing to production).
With only a few client plugins / css packages this is becoming quite annoying.
NOTE: Renaming files/directories retrieved by bower.io to have a leading '.' or using bower in a dotted subdirectory helps only marginally. I would then have to manually include the files needed.
Is this possibly a duplicate of How to exclude directories/files from Meteor's bundler?
If you want to define the way you name your files, you could try including a certain regex to match in the meteor bundler. Otherwise, maybe it's something that needs to be implemented on a framework level.
I also found this tutorial by Tri on integrating meteor and bower: http://tridnguyen.com/articles/meteor-and-bower/. Tri defines a new meteor package to specify the exact files required on the client.
The best solution, however, is move away from Bower as Meteor offers its own package manager at a framework level. Including the front end files that you need using Meteor packages would be the more productive solution in the long run, especially as the framework changes.