Comments (13)
from webpacker.
With regards to the current directory structure, the most meaningful change would be to consider changing the name of /app/javascript
to something that reflects /app/javascript-and-friends
. We actually had exactly this original situation with React on Rails. I started out calling it javascript
and some of my engineers suggested the name change to /client
. And it's not a huge deal to just "know" that /app/javascript
does include non-javascript.
Here are few naming ideas. I'd consider changing the usage of the word "pack" to "bundle" as that's already commonly used in the Webpack space. See #136.
/app/client
and /app/client/packs
or /app/client/bundles
/app/webpack
and /app/webpack/packs
or /app/webpack/bundles
.
Regardless of changing any default naming, so long as we can configure the locations for:
/app/javascripts
/node_modules
/config/webpack
Then we'll have an easy migration path for Rails 5.0 react_on_rails apps to migrate without huge movements of the files out of the /client
directory, which is 100% popular with the existing React on Rails community.
For new React on Rails installs with its generator, I'll do the simplest thing possible, which is to go with whatever is the rails standard. In fact, the yarn and webpacker integration will make the React on Rails install even smoother and easier! I'm excited about that, and I hope to have a PR ready very shortly.
from webpacker.
@justin808 Really dig react-on-rails, you've clearly done a ton of thinking and work on these issues 🙂 . Going to chime in with my two-cents anyway though.
The way webpacker has it now seems about right to me. Railsy but still compatible with node.js/webpack tooling. Some questions about the centralized client directory approach:
- Having a new top-level directory seems like it should be avoided if at all possible
- Two package.json files seems kinda weird, right?
- Where does stuff build to under this setup?
public/client
? - Not sure I understand the problem this solves. Can't webstorm/atom/ide users just open the root directory for the project?
I guess I feel like this is a pretty major departure from the basic approach of the gem so far? Should it maybe be another gem?
from webpacker.
+1, it is convenient in many cases to work with all the client code in the same directory tree, not to mention not having to have as many jump-up-and-back-down dot-proliferation in relative path references of webpack and package.json files.
from webpacker.
+1 to Justin's last comment - these changes seem reasonable, helpful improvements, and to not go against any Rails conventions.
from webpacker.
@justin808 At this time I don't see the default changing to being a component-based pitch, but totally happy to see it be configurable. There are people who like component-based structuring of their serverside Rails code as well, and we should certainly be welcoming of that. So 👍 on making whatever configuration points we need such that you can go with a component-based structure for your plugin and projects.
from webpacker.
@dhh Would you be open to having a top level YAML file in a rails project that could allow some of these directory customizations. Something like /rails.yml
. I could look into making webpacker customizable using the settings in this file, with the defaults staying as you've defined them.
And then, going forward, we can have this file contain any custom directory mappings and common scripts for tools like Webpacker and React on Rails.
Off the top of my head, the directories and scripts that need the mapping are:
- Location of
/node_modules
- Location of webpack assets,
/app/javascripts
- Location of webpack configuration files,
/config/webpack
- A few key scripts for building webpack assets:
- Static development build
- Static production build
- maybe running rails with hot reloading...
Once I get into the modifications, I'll better be able to specify what needs to go into the /rails.yml
Having a YML file will make configuration easier and more obvious than using environment variables for things that are project specific.
from webpacker.
I don't think we need a new configuration file to accomplish this. We already have a good configuration system that has worked well enough for configuring the asset pipeline as well. So let's just extend that.
What are the alternative placements that you have in mind for node_modules or config/webpack?
from webpacker.
I don't think we need a new configuration file to accomplish this.
I think it would be nicer if scripts (like the webpack configs) do not have to parse Ruby code. A more generic configuration readable by both the webpack and ruby config files is either JSON or YAML.
How about we allow some optional overrides from the defaults in /package.json
. Extra keys are allowed per the guidelines specified here.
What are the alternative placements that you have in mind for node_modules or config/webpack?
We have a large base of production apps that are on the standard of putting all webpack related items to be quarantined in /client
. This includes the node modules, the webpack configs, the client side JS, CSS, Images, Fonts, etc., and the "real" package.json used. The top level package.json defers to this directory. The "nice" thing about this organization is that you can use JS editors within the /client
directory.
How about if I made a PR where the directory names have the current defaults but can be overridden in /package.json, and the webpacker scripts will check on that?
{
"rails": {
"clientFiles": "./app/javascripts",
“deploymentDirectory”: “./assets/webpack”,
"nodeModules": "./node_modules"
}
dependencies: {
}
// etc.
}
I'm not sure if the location of the /config/webpack
directory for the webpack files matters so much as typically scripts in package.json will invoke the webpack executable with the location of the config file like this:
"scripts": {
"build:client": "webpack --config webpack.client.rails.build.config.js",
}
from webpacker.
I see. I'm not sure this adds that much over just changing the webpacker binstubs, for example. The code is generated, not hidden inside of Rails, so it's all there for the changing. The same goes for the webpack configs themselves.
I was more thinking if there are any configs within Rails, like for the view helpers, that need specialization, we can provide options for that. But otherwise I think it's fine for someone to tailor all the generated files.
from webpacker.
Hi @dhh! I'd like to see any yaml or json standard place for a configuration that is not environment specific. The reason is that with JavaScript files, it's quite inconvenient to have to write a ruby binstub script to read a ruby configuration file and to then put whatever value into some environment values.
Current Ruby Way
ruby-config ==> parsing or loading ==> set env value before calling JS file
Proposed way
JS file (and Ruby files) read a standard JSON OR YAML configuration
Details
We could have a simple configuration file (or use the package.json
and a rails
section), from which we can read values into from our webpack configs and other JavasScript files. While ENV values can work, it's not easy for the simple task of git clone and then running an app.
Plus, I think there's an expectation that env specific files like development.rb
will override what's in application.rb
. This sort of default and override is commonly done in the database.yml
file. The below code in the binstub assumed the value would only be in development.rb
While any gem can create their own standard configuration (as we did by putting EVERYTHING JavasScript under /client
) or mechanisms for configuration, I'd like to see something that's more easily readable by JavaScript. Yaml parsing can be done by js-yaml which had almost 14 million downloads last month. So YAML parsing is popular.
For example, consider this:
https://github.com/rails/webpacker/blob/master/lib/install/bin/webpack-dev-server.tt#L20
# Look into the environment file for a non-commented variable declaration
unless File.foreach(File.join(APP_PATH, RAILS_ENV_CONFIG)).detect { |line| line.match(/^\s*[^#]*config\.x\.webpacker\[\:dev_server_host\].*=/) }
puts "Warning: if you want to use webpack-dev-server, you need to tell Webpacker to serve asset packs from it. Please set config.x.webpacker[:dev_server_host] in #{RAILS_ENV_CONFIG}.\n\n"
end
This could be checking if a value is configured in the YAML or JSON file.
from webpacker.
An example of the json suggestion is being implemented by @gauravtiwari in #153. It looks like a great direction based on the code. For example, to read a setting:
const { webpacker } = require('../../package.json').config
const distDir = webpacker.distDir
From https://github.com/rails/webpacker/pull/153/files#diff-67f77b829953e34e910db8d7c0c285c3R9
from webpacker.
@justin808 We can close this one. #153 is now merged that addresses this
from webpacker.
Related Issues (20)
- Webpacker 6 Disable Babel HOT 1
- Webpacker compilation takes more than 1.5 hours HOT 11
- How do I allow a package in node_modules to be processed by babel? HOT 1
- Remove addition of node_modules to Rails.application.config.assets.paths HOT 1
- V6 Status HOT 3
- Raise an error when javascript_pack_tag or stylesheet_pack_tag are called more than once HOT 1
- Regular Expression Denial of Service in postcss HOT 2
- Intermittent Webpacker.dev_server.running? behavior HOT 2
- Host for assets from a webpacker configuration using custom domains not being resolved HOT 2
- Cherry-pick "Nothing to do" logging update onto `5.x` HOT 1
- Rails 6 WebPacker is not calling JQuery inside views HOT 1
- Security Vulnerability in [email protected] HOT 2
- currently no loaders are configured to process this file HOT 1
- Incompatibility with Ruby 3.2.0 HOT 2
- Confusing gem description on RubyGems HOT 1
- Npm package for 5.4.4 was not released HOT 2
- class variable @@local_levels of ActiveSupport::Logger is overtaken by Logger HOT 2
- Trying to deploy but assets assets:precompile fail
- Security Vulnerability for postcss
- Postcss Security Vulnerability
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from webpacker.