Until now, Rails only droped compatibility with older
rubies on new majors, but I propose to change this policy
because it causes us to either keep compatibility with long
EOLed rubies or to bump the Rails major more often, and to
drop multiple Ruby versions at once when we bump the major.
In my opinion it's a bad alignments of incentives. And we'd
be much better to just drop support in new minors whenever they
go EOL (so 3 years).
Also Ruby being an upstream dependency, it's not even
a semver violation AFAICT.
Since Rails 7.2 isn't planned before a few months, we
can already drop Ruby 3.0 as it will be EOL in March.
actioncable.js and actioncable.esm.js is not included to gem package. It prevented us from using the action cable when using importmaps.
This adds the missing asset files to gem package.
We had a discussion on the Core team and we don't want to expose this information
as a JSON endpoint and not by default.
It doesn't make sense to expose this JSON locally and this controller is only
accessible in dev, so the proposed access from a production app seems off.
This reverts commit 8eaffe7e89719ac62ff29c2e4208cfbeb1cd1c38, reversing
changes made to b6e4305c3bca4c673996d0af9db0f4cfbf50215e.
Generally followed the pattern for https://github.com/rails/rails/pull/32034
* Removes needless CI configs for 2.4
* Targets 2.5 in rubocop
* Updates existing CHANGELOG entries for fewer merge conflicts
* Removes Hash#slice extension as that's inlined on Ruby 2.5.
* Removes the need for send on define_method in MethodCallAssertions.
We've replaced the sprockets `//= require` directives with ES2015
imports. As a result, the ActionCable javascript can now be compiled
with rollup (like ActiveStorage already is).
- Rename action_cable/index.js.erb -> action_cable/index.js
- Add rake task to generate a javascript module of the ActionCable::INTERNAL ruby hash
This will allow us to get rid of ERB from the actioncable javascript,
since it is only used to interpolate ActionCable::INTERNAL.to_json.
- Import INTERNAL directly in ActionCable Connection module
This is necessary to remove a load-order dependency conflict in the
rollup-compiled build. Using ActionCable.INTERNAL would result in a
runtime error:
```
TypeError: Cannot read property 'INTERNAL' of undefined
```
because ActionCable.INTERNAL is not set before the Connection module
is executed.
All other ActionCable.* references are executed inside of the body of a
function, so there is no load-order dependency there.
- Add eslint and eslint-plugin-import devDependencies to actioncable
These will be used to add a linting setup to actioncable like the one
in activestorage.
- Add .eslintrc to actioncable
This lint configuration was copied from activestorage
- Add lint script to actioncable
This is the same as the lint script in activestorage
- Add babel-core, babel-plugin-external-helpers, and babel-preset-env devDependencies to actioncable
These will be used to add ES2015 transpilation support to actioncable
like we have in activestorage.
- Add .babelrc to actioncable
This configuration was copied from activestorage
- Enable loose mode in ActionCable's babel config
This generates a smaller bundle when compiled
- Add rollup devDependencies to actioncable
These will be used to add a modern build pipeline to actioncable like
the one in activestorage.
- Add rollup config to actioncable
This is essentially the same as the rollup config from activestorage
- Add prebuild and build scripts to actioncable package
These scripts were copied from activestorage
- Invoke code generation task as part of actioncable's prebuild script
This will guarantee that the action_cable/internal.js module is
available at build time (which is important, because two other modules
now depend on it).
- Update actioncable package to reference the rollup-compiled files
Now that we have a fully functional rollup pipeline in actioncable, we
can use the compiled output in our npm package.
- Remove build section from ActionCable blade config
Now that rollup is responsible for building ActionCable, we can remove
that responsibility from Blade.
- Remove assets:compile and assets:verify tasks from ActionCable
Now that we've added a compiled ActionCable bundle to version control,
we don't need to compile and verify it at publish-time.
(We're following the pattern set in ActiveStorage.)
- Include compiled ActionCable javascript bundle in published gem
This is necessary to maintain support for depending on the ActionCable
javascript through the Sprockets asset pipeline.
- Add compiled ActionCable bundle to version control
This mirrors what we do in ActiveStorage, and allows ActionCable to
continue to be consumed via the sprockets-based asset pipeline when
using a git source instead of a published version of the gem.
nio4r 2.0.0 primarily includes new features and bugfixes, with few breaking
changes. The primary reason for bumping the major version is dropping support
for all Ruby versions prior to 2.2.2, so as to match Rails 5.
Full release announcement here:
https://groups.google.com/forum/#!topic/socketry/ZDIUj1ufiJ8
Apps that depend on Action Cable don't need Blade for app development,
so we can remove the gem dependency.
We do need Blade for Action Cable dev, so we bundle it in the Gemfile.
Signed-off-by: Jeremy Daer <jeremydaer@gmail.com>
This removes 8 runtime gem dependencies from Rails:
```
Using hitimes 1.2.3
Using timers 4.1.1
Using celluloid-essentials 0.20.5
Using celluloid-extras 0.20.5
Using celluloid-fsm 0.20.5
Using celluloid-pool 0.20.5
Using celluloid-supervision 0.20.5
Using celluloid 0.17.2
```
