Is enabling full source maps in production a wise default? (2017)
2 points · Open discussionrails
webpacker
Ruby2016–2022
rails / webpacker
webpacker
Use Webpack to manage app-like JavaScript modules in Rails
21Distinct people
22Mentions
0Explicit recommenders
5.3KGitHub stars
What to know before exploring
What it is
Use Webpack to manage app-like JavaScript modules in Rails
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
- rails/rails · linked in 2 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 1:49:46 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year22 dated mentions
Observed mentions: 2016-12-09 06:14:56 UTC to 2022-10-13 19:01:41 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 3 | 1 | 2 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 7 | 3 | 4 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 6 | 4 | 2 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 3 | 2 | 1 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
Webpacker has been retired 🌅
Webpacker has served the Rails community for over five years as a bridge to compiled and bundled JavaScript. This bridge is no longer needed for most people in most situations following the release of Rails 7. We now have three great default answers to JavaScript in 2021+, and thus we will no longer be evolving Webpacker in an official Rails capacity.
For applications currently using Webpacker, the first recommendation is to switch to jsbundling-rails with Webpack (or another bundler). You can follow the switching guide, if you choose this option.
Secondly, you may want to try making the jump all the way to import maps. That's the default setup for new Rails 7 applications, but depending on your JavaScript use, it may be a substantial jump.
Finally, you can continue to use Webpacker as-is. We will continue to address security issues on the Ruby side of the gem according to the normal maintenance schedule of Rails. But we will not be updating the gem to include newer versions of the JavaScript libraries. This pertains to the v5 edition of this gem that was included by default with previous versions of Rails.
The development of v6 will not result in an official gem released by the Rails team nor see any future support. But Justin Gordon is continuing that line of development – including a focus on hot-module reloading features etc – under a new gem called Shakapacker that is based on the unreleased v6 work from this repository.
Thank you to everyone who has contributed to Webpacker over the last five-plus years!
Please refer to the 5-x-stable branch for 5.x documentation.
Read the full README on GitHubWhat Hacker News says
22 sourcesThat's completely fair. I think the analogy to SQL as an API is very apt. No one would argue that full SQL access isn't a powerful API but it takes some legwork to understand the schema and write queries to get the data you need.
There's a divide between at least two types of persona here. On one side is integrators building products and features on top of the GitHub API. For these people GraphQL is arguably superior since the learning curve is manageable and in exchange for scaling it you can make an extremely specific query that returns your product's exact data requirements. The cost of writing this query is amortized over the lifetime of your integration.
On the other side are e.g. users automating some part of their GitHub workflow to save themselves time. I can see how the REST API feels like a better choice here, it's certainly
Read the rest
simpler to get started with.
For what it's worth, here[0] is an example of using the `gh` CLI's graphql feature to print a list of all repository URLs for a given organization by login, sorted in a relatively complicated way. It's more verbose than doing this with the REST API but significantly more flexible. This could just as easily be done with curl but as others have pointed out, pagination requires a minimal level of logic to implement, so it's more convenient to use an existing helper. This output gets flushed 10 lines at a time as pages come in, making it suitable to compose with other commands using pipes.
$ gh api graphql --paginate -f query='
query($endCursor: String) {
organization(login: "rails") {
repositories(first: 10, after: $endCursor,
orderBy: { field: STARGAZERS, direction: DESC }
) {
nodes {
url
stargazers {
totalCount
}
}
pageInfo { endCursor hasNextPage } # needed for auto-pagination
}
}
}' -q '.data.organization.repositories.nodes.[]'
# output follows
{"stargazers":{"totalCount":50643},"url":"https://github.com/rails/rails"}
{"stargazers":{"totalCount":5298},"url":"https://github.com/rails/webpacker"}
{"stargazers":{"totalCount":4849},"url":"https://github.com/rails/thor"}
{"stargazers":{"totalCount":4075},"url":"https://github.com/rails/jbuilder"}
# snip
{"stargazers":{"totalCount":3},"url":"https://github.com/rails/hide_action"}
{"stargazers":{"totalCount":2},"url":"https://github.com/rails/gem-buildkite-config"}
{"stargazers":{"totalCount":2},"url":"https://github.com/rails/sqlite2_adapter"}
{"stargazers":{"totalCount":1},"url":"https://github.com/rails/fcgi_handler"}
[0]: https://gist.github.com/brasic/14222db7b3f5873b84820477cca27...
I agree wholeheartedly. Often these arguments look like the curmudgeons vs the crazy kids, but it's a deeper philosophical point.
The web should be accessible. Accessible to use. Accessible to build.
Related to this, I was heartened to see DHH revert a decision in webpacker to show full source maps the other day.
> I've learned so much from View Source over the years. From structure, to CSS, to JS. That has gotten harder with minification and transpiling. That's a real shame. The web has given us so much. The default should be to give back, in all the ways we can. View Source is a heritage feature that a framework like Rails should go out of its way to pay tribute to.
https://github.com/rails/webpacker/issues/769#issuecomment-4...
In HTML, CSS and our vanishing industry entry pointsRails webpacker re-enables source maps as default
2 points · Open discussionRails 6: enabled full source maps in production
1 points · Open discussionIs enabling full source maps in production a wise default?
1 points · Open discussionDHH on enabling source maps by default on Rails production apps
2 points · Open discussion"Rails... ...doesn't play well with SPAs"
Huh? Rails ships with built-in, no-config webpack support (https://github.com/rails/webpacker#installation) as well as install tasks for the most-popular front-end solutions (https://github.com/rails/webpacker#integrations)
In The melting pot of JavaScript (2017)Rails 5 already has webpack support and React support.
https://github.com/rails/webpacker
https://github.com/reactjs/react-rails
Can use it pretty much fully in place of the asset pipeline.
Can use standard ERB and spice it up with React using a simple tag with the component name and props as a hash.
In Responder: A familiar HTTP Service FrameworkAFAIK anyway, Webpack isn't automatically installed with every Rails app but is easily available via https://github.com/rails/webpacker. So it's not "bundled" necessarily all the time, but is quite trivially added to a Rails project.
If your question is more like "why the hell would you ever want to run Webpack and Rails simultaneously together":
You will increasingly find tools you want to use that more-or-less require Webpack (or a similar JS build tool). Because of things like e.g. the asset pipeline, it's extremely frustrating trying to get those tools to work in concert with each other as micro-services that know nothing about each other. It's much easier to use something like Webpacker so they can play nicely with each other.
In Rails, still?Laravel Mix[0], Rails Webpacker[1], and Dotnet's Spa Services[2] (among others) all do fantastic jobs getting you going with new frontend tech alongside backend apps. It's kind of amazing that the JS world does a bit of a worse job here. Too much focus on the hip new way vs getting things done? Seems boilerplate exists mostly to make "Universal" apps now, but I've yet to see a straightforward attempt at that (not to mention, the distinction for things that work in-browser vs not is going to be confusing for beginners in the single-language-JS approach). create-react-app is fine but it only does half the job.
[0] https://laravel.com/docs/5.5/mix
[1] https://github.com/rails/webpacker
[2] https://blogs.msdn.microsoft.com/webdev/2017/02/14/building-...
In I Don't Want to Configure Apps (2016)> Finally, when it comes to interface development, nothing in rails will get you as far as React these days
Rails's out-of-the-box React integration [1] should get you _exactly_ as far as React these days.
[1] https://github.com/rails/webpacker#react
In Ask HN: Is Ruby on Rails still worth it?Advanced React integration (with Rails 5.1 Webpacker)
1 points · Open discussionShowing the 15 most recent of 22 sources. Enable JavaScript to search and browse every indexed mention.