* Update nvmrc to Node.js 16
* Update package.json minimum Node engine to 16
* Update README requirements to Node.js 16
* Update devcontainer Node.js version to 16
* Update devcontainer Dockerfile Node.js choices to LTS versions that are still in support/maintenance
* Pin CircleCI Node image to 16
* Fix YAML type issue
* Update CircleCI Node.js to 16.18 to match #22019
* Update nvmrc to Node.js 16
* Update package.json minimum Node engine to 16
* Update README requirements to Node.js 16
* Update devcontainer Node.js version to 16
* Update devcontainer Dockerfile Node.js choices to LTS versions that are still in support/maintenance
* Pin CircleCI Node image to 16
* Fix YAML type issue
* Update CircleCI Node.js to 16.18 to match #22019
* Improve devcontainer for running tests
- Pull devcontainer post-create out into its own script
- Add asset precompilation
- Add test-mode asset precompilation (needed to run tests without error)
* Document Gemfile.lock re-checkout in devcontainer
* Improve devcontainer for running tests
- Pull devcontainer post-create out into its own script
- Add asset precompilation
- Add test-mode asset precompilation (needed to run tests without error)
* Document Gemfile.lock re-checkout in devcontainer
When opening a page such as /web/timelines/home in a desktop browser, the
cursor was automatically placed in the textarea of the compose form.
When using the keyboard for navigation (using a browser plugin like vimium or
vim vixen, or just to hit 'space' to scroll down a page), you have remember to
leave the field before using that.
Since you only visit the page to write a new post some of the time, this PR
attempts to have nothing focused initially (and require the user to click or
e.g. use 'tab' to focus the textarea).
Tested:
* /web/timeslines/home no longer autofocuses the compose box
* pressing the 'n' hotkey still focuses the compose box
* clicking 'reply' for a post still focuses the compose box
* replying to a CW'ed post still focuses the compose box
* introducing the CW field still focuses the CW field
* introducing the CW field for a reply still focuses the CW field
* removing the CW field still focuses the compose box
* /web/statuses/new still autofocuses the compose box
fixes#15862
When opening a page such as /web/timelines/home in a desktop browser, the
cursor was automatically placed in the textarea of the compose form.
When using the keyboard for navigation (using a browser plugin like vimium or
vim vixen, or just to hit 'space' to scroll down a page), you have remember to
leave the field before using that.
Since you only visit the page to write a new post some of the time, this PR
attempts to have nothing focused initially (and require the user to click or
e.g. use 'tab' to focus the textarea).
Tested:
* /web/timeslines/home no longer autofocuses the compose box
* pressing the 'n' hotkey still focuses the compose box
* clicking 'reply' for a post still focuses the compose box
* replying to a CW'ed post still focuses the compose box
* introducing the CW field still focuses the CW field
* introducing the CW field for a reply still focuses the CW field
* removing the CW field still focuses the compose box
* /web/statuses/new still autofocuses the compose box
fixes#15862
* fix(rubocop): update gems and add performance and rspec
fix(rubocop): update gems and add performance and rspec
- update present rubocop gems
- add rubocop-rspec and rubocop-performance gems
- move rubocop gems to gem group :development, :test in order to
make linting in a github action that runs with RAILS_ENV=test possible
* feat(rubocop): disable some annoyance RSpec cops
To mee these prooved to be more annoying than helpful.
If not agreed, they can be enabled any time.
* fix(rubocop): do not ignore spec/**/*
Because rubocop-rspec should lint the specs as well, and they
deserve to be readable in general. It is relevant code, after all.
* fix(rubocop): change ignore db/**/* to db/schema.rb
because rails cops do some lints for migrations.
E.g. reversable migrations linting and more.
* fix(rubocop): tune rules configs
Bunch of commits squashed:
fix(rubocop): enable Layout/LineLength cop
Because this project has code with line lenghts > 500 chars.
This is not good practice at all, so I strongly suggest to
change the practice in the future.
But allow heredoc, URI and comments to still be long lines
and make the default Max: 120 explicit, by repeating it in the
config. To me this max length seems reasonable. Perhaps
a bit more could be ok for some. But > 500 chars in one line
Seems to be way too long IMHO.
fix(rubocop): Metrics/CyclomaticComplexity Max to 12
The default is 7, perhaps quite strict. But 25 is too loose,
the rule becomes pointless like that.
fix(rubocop): AllCops ruby version, cacheing and more info
- fix the target ruby version from 2.5 to 3.0
- have the cop error messages to be more informative and helpful
- enable cacheing in /tmp
fix(rubocop): Metrics/AbcSize to 34 from 115
Rubocops default is 17. If the rule is at 115 is becomes
pointless.
fix(rubocop): Metrics/BlockLength improvements
- instead of ignoring tasks completely, ignore only the
long blocks that are specific to tasks (task, namespace)
- ignore also concern specific block methods (included, class_methods)
fix(rubocop): Metrics/ClassLength count heredoc array as one line
fix(rubocop): Metrics/MethodLength Max to 25
- the default is 10, but 65 is too loose, so perhaps 25?
fix(rubocop): Metrics/ModuleLength array and heredoc count as one
fix(rubocop): Metrics/PerceivedComplexity to 16 from 25
Rubocops default is 8, so how about only doubling that, instead
of > than tripple it?
fix(rubocop): enable Style/RedundantAssignment
Because I think that this rule would never really hurt,
but improve code quality and readability.
fix(rubocop): enable Style/RescueStandardError
I think everyone that ever had to debug what this can bring
will hopefully agree that this rule totally makes sense.
In the super rare exeptions where this is totally needed,
it can be excluded by disabling comment in that place.
fix(rubocop): Metrics/ParameterLists add explicit defaults and some excludes
* fix(rubocop): update gems and add performance and rspec
fix(rubocop): update gems and add performance and rspec
- update present rubocop gems
- add rubocop-rspec and rubocop-performance gems
- move rubocop gems to gem group :development, :test in order to
make linting in a github action that runs with RAILS_ENV=test possible
* feat(rubocop): disable some annoyance RSpec cops
To mee these prooved to be more annoying than helpful.
If not agreed, they can be enabled any time.
* fix(rubocop): do not ignore spec/**/*
Because rubocop-rspec should lint the specs as well, and they
deserve to be readable in general. It is relevant code, after all.
* fix(rubocop): change ignore db/**/* to db/schema.rb
because rails cops do some lints for migrations.
E.g. reversable migrations linting and more.
* fix(rubocop): tune rules configs
Bunch of commits squashed:
fix(rubocop): enable Layout/LineLength cop
Because this project has code with line lenghts > 500 chars.
This is not good practice at all, so I strongly suggest to
change the practice in the future.
But allow heredoc, URI and comments to still be long lines
and make the default Max: 120 explicit, by repeating it in the
config. To me this max length seems reasonable. Perhaps
a bit more could be ok for some. But > 500 chars in one line
Seems to be way too long IMHO.
fix(rubocop): Metrics/CyclomaticComplexity Max to 12
The default is 7, perhaps quite strict. But 25 is too loose,
the rule becomes pointless like that.
fix(rubocop): AllCops ruby version, cacheing and more info
- fix the target ruby version from 2.5 to 3.0
- have the cop error messages to be more informative and helpful
- enable cacheing in /tmp
fix(rubocop): Metrics/AbcSize to 34 from 115
Rubocops default is 17. If the rule is at 115 is becomes
pointless.
fix(rubocop): Metrics/BlockLength improvements
- instead of ignoring tasks completely, ignore only the
long blocks that are specific to tasks (task, namespace)
- ignore also concern specific block methods (included, class_methods)
fix(rubocop): Metrics/ClassLength count heredoc array as one line
fix(rubocop): Metrics/MethodLength Max to 25
- the default is 10, but 65 is too loose, so perhaps 25?
fix(rubocop): Metrics/ModuleLength array and heredoc count as one
fix(rubocop): Metrics/PerceivedComplexity to 16 from 25
Rubocops default is 8, so how about only doubling that, instead
of > than tripple it?
fix(rubocop): enable Style/RedundantAssignment
Because I think that this rule would never really hurt,
but improve code quality and readability.
fix(rubocop): enable Style/RescueStandardError
I think everyone that ever had to debug what this can bring
will hopefully agree that this rule totally makes sense.
In the super rare exeptions where this is totally needed,
it can be excluded by disabling comment in that place.
fix(rubocop): Metrics/ParameterLists add explicit defaults and some excludes
* Use Rails tag API to build RSS feed for spoilers and polls
While the previous method did not contain a bug or a potential issue,
the tag API can be very resilient against future problems and reduces the
amount of manual management of the escape status of the content.
I've added tests to ensure that the formatting is broken and still
escapes control characters correctly.
* this seems cleaner and passes
* Incorporate feedback by moving the br to its own line and using the tag helper over the string constant for the br tag itself
* whoops, tag helper doesn't use a self-closing tag
* Use Rails tag API to build RSS feed for spoilers and polls
While the previous method did not contain a bug or a potential issue,
the tag API can be very resilient against future problems and reduces the
amount of manual management of the escape status of the content.
I've added tests to ensure that the formatting is broken and still
escapes control characters correctly.
* this seems cleaner and passes
* Incorporate feedback by moving the br to its own line and using the tag helper over the string constant for the br tag itself
* whoops, tag helper doesn't use a self-closing tag
The smaller border is difficult to see for some users, especially
when the browser window was thinner, and so the unread border is at the
very left edge of the window.
The smaller border is difficult to see for some users, especially
when the browser window was thinner, and so the unread border is at the
very left edge of the window.
