ESLint documentation moved from MDN and updated

I've just transferred the ESLint documentation that was on MDN and integrated it in the existing documentation on Firefox source docs. This has also been updated, and the ESLint page now has an updated section on

Please run mach bootstrap; NodeJS/NPM security fixes landed

* Upgrades for NodeJS from 10.21.0 to 10.22.1 and for NPM from 6.14.4 to 6.14.6 have merged to mozilla-central. * Everyone is encouraged to run `mach bootstrap` to upgrade the toolchain on their machine. * The main security fix that we’re concerned with is in node, so I’ve also

Re: Intent to unship: window.external.AddSearchProvider

On 28/04/2020 16:22, Tom Schuster wrote: > As the author of one of these extensions for adding a custom search > engine > (https://addons.mozilla.org/en-US/firefox/addon/add-custom-search-engine/) > I am of course disappointed, but not actually surprised. This is > basically round two from about

Intent to unship: window.external.AddSearchProvider

As of Firefox 78, I intend to change `window.external.AddSearchProvider` in Firefox to be a dummy function. This will be a preference switch initially, with the original implementation code being removed fully in Firefox 79. /Status/: * The HTML Standard specifies this method

ESLint: nullish coalescing and optional chaining operators now available for use

Last week we finished landing support for the nullish coalescing and optional chaining operators in ESLint

ESLint now enabled for all of mozilla-central

Yesterday, I landed the last patch to enable ESLint on all our javascript code in mozilla-central*. You can read more about this in my blog post (tweet

Re: Intent to ship: Optional Chaining Operator

ESLint doesn't implement new features until they are stage 4, so it tends to lag behind a bit. Hence at the moment, you won't be able to use these in our code. ESLint's tracking issue is here , and it looks like they've started working on it, so

ESLint: Third-party paths are now obtained from ThirdPartyPaths.txt

tl;dr ESLint has just moved reading third-party paths from .eslintignore to ThirdPartyPaths.txt. A couple of bugs have just landed on central which have updated ESLint and changed how we

Recent ESLint updates - BigInt, improved autofixing and more

Over the last couple of weeks we landed a couple of ESLint updates which support new features and fix a few issues. Here's a quick summary: * BigInt is now supported. * For globals defined via /*

PSA: Changes to ESLint & HTML mainly affecting Sublime Text users

tl;dr We've changed ESLint's configuration to enable HTML parsing by default for better editor integration. Sublime Text users will need to change configuration. Up until now the ESLint configuration in mozilla-central has been with the html plugin not enabled, but to enable it when `./mach

New xpcshell-test option to aid debugging failures when run in parallel

tl;dr We now have a --verbose-if-fails option that outputs a log if a xpcshell-test fails when being run in parallel. If you ever have seen output from xpcshell-tests like this:  0:05.68 TEST_START: toolkit/components/search/tests/xpcshell/test_remove_profile_engine.js 0:08.57 TEST_END: FAIL

PSA: .eslintrc.js files are no longer needed in test directories (in most cases)

tl;dr I've just landed bug 1415265 which means you no longer need .eslintrc.js files extending the configuration in commonly-named directories. Since early in the ESLint days, we've needed extra configuration files in our test

Re: PSA: Dangling Commas landing part 2 - 20th Oct

On 03/10/2018 15:45, Mark Banner wrote: Following the successful enabling of the ESLint comma-dangle rule for some of our javascript files, I am intending on enabling it for the rest on Friday 20th October. ... Bug 1486741 <https://bugzilla.mozilla.org/show_bug.cgi?id=1486

What's next for ESLint on Firefox Source Code?

A couple of days ago I blogged about what's next for ESLint on mozilla-central. In case you haven't seen it already, you can read about it here: https://www.thebanners.uk/standard8/2018/10/03/whats-next-for-eslint-on-firefox-source-code/ Feedback welcome, on the blog or direct to me. Mark.

PSA: Dangling Commas landing part 2 - 20th Oct

Following the successful enabling of the ESLint comma-dangle rule for some of our javascript files, I am intending on enabling it for the rest on Friday 20th October. This is at the end of the soft freeze period, but just before the merges happen, to make uplifts easier. This will affect

Looking for an implementer for a improvement to SublimeLinter-ESlint

Hi all, I am trying to improve our ESLint configuration, especially around HTML files. One of the things that limits us in the ideal scenario is the SublimeLinter-ESLint plugin. The plugin currently does its own work for html files which stops working when eslint-plugin-html is enabled

Re: Plan for Sunsetting MozReview

On 05/09/2018 04:40, Kris Maglione wrote: Concur. Aside from future-proofing things, reading comments in phabricator is pretty painful, especially for bugs with multiple patches. With the old flow, I could look at all of them in one place. Now, I have to open a half dozen separate pages, and

Re: Proposal: Require dangling commas for multiline objects/arrays on all Javascript mozilla-central code

On 22/08/2018 21:29, Mark Banner wrote: Since there are a large amount of instances (approx 12k) that would need to be fixed across the code base, I would propose that we roll it out on a per-directory basis. For example, we could do all of browser/ at the start of the 64 cycle just after

Proposal: Require dangling commas for multiline objects/arrays on all Javascript mozilla-central code

I would like to propose that we require dangling commas for multi-line object/arrays in Javascript code for mozilla-central. Why: * Multiple components in toolkit/ and browser/ already have comma-dangle enabled .

Re: Intent to ship: application/json mime type support for OpenSearch Suggestions

On 20/06/2018 22:14, Eric Shepherd (Sheppy) wrote: Is there a bug number for this? I was not able to find one. Sorry, I missed that: https://bugzilla.mozilla.org/show_bug.cgi?id=1425827 Mark. ___ dev-platform mailing list

Intent to ship: application/json mime type support for OpenSearch Suggestions

In the draft OpenSearch specifications [1], there is ambiguity of the required mime type for providing suggestions for search providers. Currently, the Suggestions extension [2] specifies "application/x-suggestions+json", however the example given in the main specification uses

Intent to Unship: support

In bug 1452645 [1] we are planning to remove the "Load this bookmark in sidebar" feature. As part of this we will also be removing support for rel="sidebar" in anchor elements. In the future, anchor elements with rel="sidebar" will be treated like normal anchor elements. We are planning to

Intent to require Node 8.9.1/npm 5.5.1 for ESLint

I would like to increase the minimum requirements for node with ESLint to node v8.9.1, npm v5.5.1 for the following reasons: * ESLint 5.x is now in alpha, and raises its minimum node requirement level to 6.14.0 (ours is currently 6.9.1) * MozillaBuild & our automation already use node

Re: Intent To Require Manifests For Vendored Code In mozilla-central

On 10/04/2018 05:25, glob wrote: The plan is to create a YAML file for each library containing metadata such as the homepage url, vendored version, bugzilla component, etc. See https://goo.gl/QZyz4xfor the full specification. There are some directories where we only import a file from a

PSA: Possible Issues running ESLint (could not load globals from file)

We've had a few reports of issues when running ESLint in mozilla-central. The have tended to be along the lines of: Could not load globals from file browser.js: Error: Invalid ecmaVersion. If you get this, please check if you have a /tools/lint/eslint/node_modules/ directory, if so: -

Re: Most definitions of Ci, Cr, Cc, and Cu have been removed from the tree

On 08/02/2018 08:56, Mark Banner wrote: On 07/02/2018 00:38, Andrew McCreight wrote:   Following up on my previous post, I have just landed (in bug 1432992) the removal of most of the definitions of Ci, Cr, Cc, and Cu. This touched almost 2000 files, so it may affect your patches

Re: Most definitions of Ci, Cr, Cc, and Cu have been removed from the tree

On 07/02/2018 00:38, Andrew McCreight wrote: Following up on my previous post, I have just landed (in bug 1432992) the removal of most of the definitions of Ci, Cr, Cc, and Cu. This touched almost 2000 files, so it may affect your patches, but hopefully rebasing is easy. For those wanting an

Re: overly strict eslint rules

On 03/01/2018 14:57, Mark Banner wrote: On 24/12/2017 22:07, Masatoshi Kimura wrote: --- $ mach lint browser/base/content/aboutDialog.js eslint-plugin-html v2.0.3 should be v4.0.0. ESLint is an old version, clobbering node_modules

Re: overly strict eslint rules

On 24/12/2017 22:07, Masatoshi Kimura wrote: I got the following error when I tried it just now: As far as I know, it should work fine with the latest version of MozillaBuild. If it doesn't, please file a bug in Testing:Lint and we'll take a look.

Re: overly strict eslint rules

On 24/12/2017 19:41, Ben Kelly wrote: But I also see rules about cosmetic things like what kind of quotes must be used for strings. AFAICT this kind of rule does not have any tangible safety benefit. Its purely a cosmetic style choice. I don't see why we should bounce patches out of the tree

Re: Proposal: Stop using Object.freeze/Object.seal on most of our Javascript Objects

On 20/11/2017 13:22, Nicolas B. Pierron wrote: On 11/20/2017 10:01 AM, Mark Banner wrote: Now that we don't have legacy add-ons outside of our control, I would like to propose that we stop using Object.freeze/Object.seal on most of our objects. I would personally recommend to every

Proposal: Stop using Object.freeze/Object.seal on most of our Javascript Objects

[Resending to get the correct Firefox list] Now that we don't have legacy add-ons outside of our control, I would like to propose that we stop using Object.freeze/Object.seal on most of our objects. I believe that this was originally done to provide some extra security/stability relating to

Proposal: Stop using Object.freeze/Object.seal on most of our Javascript Objects

Now that we don't have legacy add-ons outside of our control, I would like to propose that we stop using Object.freeze/Object.seal on most of our objects. I believe that this was originally done to provide some extra security/stability relating to add-ons, i.e. stop them messing with our

experimentalObjectRestSpread now turned on for ESLint

We've just landed a patch in mozilla-central that turns on support in ESLint for Object Rest/Spread properties. Javascript support for these landed in FF 55 (bug 1339395 ), and ESLint should now let you use them. More details on the

PSA: ESlint 4 upgrade & node_modules clobber

I have just landed an upgrade to ESLint 4 on autoland, this will make its way to mozilla-central later today. One thing to note: on upgrading from ESLint 3 to 4, it will clobber your topsrcdir/node_modules directory - this is intentional to try and avoid issues we've seen previously with

Re: Experimenting with a shared review queue for Core::Build Config

On 11/10/2017 19:41, Botond Ballo wrote: On Wed, Oct 11, 2017 at 2:37 PM, Chris Cooper wrote: On Wed, Oct 11, 2017 at 1:46 PM, Nathan Froyd wrote: Does this user have a bugzilla :alias so that folks submitting patches via MozReview or similar can just

Re: We need better canaries for JS code

On 19/10/2017 14:02, Ted Mielczarek wrote: On Wed, Oct 18, 2017, at 07:51 AM, Mark Banner wrote: Looping in firefox-dev as well, as I thin this is an important discussion. On 18/10/2017 09:28, David Teller wrote: Hi everyone, Yesterday, Nightly was broken on Linux and MacOS

Re: We need better canaries for JS code

On 19/10/2017 03:29, Kris Maglione wrote: On Wed, Oct 18, 2017 at 07:22:09PM -0700, Daniel Veditz wrote: On Wed, Oct 18, 2017 at 4:51 AM, Mark Banner <mban...@mozilla.com> wrote: I did an experiment, and the only way I got an error out was to have "javascript.options.strict&quo

Re: We need better canaries for JS code

Looping in firefox-dev as well, as I thin this is an important discussion. On 18/10/2017 09:28, David Teller wrote: Hi everyone, Yesterday, Nightly was broken on Linux and MacOS because of a typo in JS code [1]. If I understand correctly, this triggered the usual "undefined is not a

PSA: Missing instances of semicolon in js files landed on inbound

We've just landed a patch to fix many instances of missing semicolons in js files onto mozilla-inbound. This are automatically fixed issues by ESLint. Some 1156 files have been changed, so

PSA: If using npm 5.0/5.0.1, please update to 5.1.0

If you've got npm 5.0 or 5.0.1 installed, please update to 5.1.0 . The latest version has a lot of fixes for its package handling when package.json is manually changed. I'll be doing some ESLint dependency updates soon which

ESLint binary location change: Update your editors (after next merge)

Continuing with the ESLint improvements, we've just landed a change on autoland that moves some of the files for ESLint setup to the root directory of mozilla-central. It should merge later today if all goes well. The change means that

PSA: ESLint no-undef rule now enabled for all of toolkit/

The "no undefined" eslint rule has now been enabled for all of toolkit/ - this landed last Friday. The devmo page has been updated with further information about the rule and some of the flags that are occasionally necessary. Enabling it

ESlint Updates

Three quick notes about updates for things we're doing with ESlint and Firefox: 1. There's a new help page on devmo with ESLint tips & advice: https://developer.mozilla.org/docs/ESLint 2. Jared has been posting about about rules being enabled on his blog: https://msujaws.wordpress.com/ 3.

PSA: Tail files now removed from xpcshell-tests

We've just landed bug 503613 [1] that removes the tail file functionality from xpcshell tests. Please use do_register_cleanup function for cleanup in future (most of our code had already been transitioned to/used this function). Standard8 [1]

Re: Strange error message on try-comm-central: Error: Invalid addon ID: expected addon ID specialpow...@mozilla.org, found special-pow...@mozilla.org in manifest

On 23/09/2016 05:01, ishikawa wrote: On 2016年09月23日 11:42, ishikawa wrote: By changing a few install.rdf as suggested, the particular error messages are gone, but I now see different failures. https://treeherder.mozilla.org/#/jobs?repo=try-comm-central=de72a169065a2bbb7f69a0e5420992bfca5a77ec

Re: Strange error message on try-comm-central: Error: Invalid addon ID: expected addon ID specialpow...@mozilla.org, found special-pow...@mozilla.org in manifest

On 22/09/2016 08:44, ISHIKAWA,chiaki wrote: 3:07:56 INFO - 1474488476446addons.xpi-utilsWARN addMetadata: Add-on specialpow...@mozilla.org is invalid: Error: Invalid addon ID: expected addon ID specialpow...@mozilla.org, found special-pow...@mozilla.org in manifest ... I am not

Re: Firefox Hello new data collection

On 04/04/2016 16:49, a...@imgland.xyz wrote: I don't know much about Mozilla's privacy but in my opinion feel the need to immediately remove it from Firefox and push a new beta build I can understand your concern, however, please understand that this logging functionality is currently

Re: Too many oranges!

On 22/12/2015 20:41, Douglas Turner wrote: My suggest was to take the n-th milestone was a strawman. I think in terms of scheduling, setting aside every n-th milestone as a quality release helps planning a bunch. When we tell customers (the web, the firefox team, firefoxos) that feature X will

Re: Voting in BMO

On 09/06/2015 23:19, R Kent James wrote: Without voting, how do you direct users to express an interest in seeing a bug solved without adding a me too comment? Maybe the answer is that we don't. We just need to be honest - it would be very difficult to create a fair system that could be used

Re: What are your pain points when running unittests?

On 13/03/2015 20:02, Gregory Szorc wrote: Another pain point: running all relevant tests. Agreed, something we've done on Loop/Hello as an intermediate step is to have a shell file which knows about all the likely relevant tests and runs them all:

Re: ES6 lexical temporal dead zone has landed on central

On 16/09/2014 09:09, Philip Chee wrote: On 16/09/2014 07:43, Shu-yu Guo wrote: Hello all, Everything inside mozilla-central needed to make the tree green on TBPL has been fixed. However, this is expected to break addons, comm-central, and possibly B2G code that use `let` (though I was told

Re: Upcoming changes to autocomplete code affecting Thunderbird

On 15/08/2014 12:55, Paolo Amadini wrote: The major change would be the removal of the multiple search sources from the autocomplete code, since this feature is used heavily by Thunderbird. For Firefox, we already developed the UnifiedComplete component that replaces the multiple searches in the

Proposal: Move Thunderbird and SeaMonkey to mozilla-central

[follow-ups to mozilla.dev.planning] tl;dr We're proposing to move Thunderbird and SeaMonkey into mozilla-central to reduce maintenance complexities for build systems, and for releng. Multiple-app handling in the same repository has improved greatly, and the general rules would remain the same.

Re: What platform features can we kill?

Maybe not quite platform features, but on the subject of removing or js replacements, I offer up a couple of candidates: http://mxr.mozilla.org/comm-central/source/mozilla/xpfe/components/directory/ I believe this is an rdf datasource for listing ftp directory pages. AFAIK this might only be

Re: review stop-energy (was 24hour review)

On 11/07/2013 12:59, Gervase Markham wrote: On 09/07/13 21:29, Chris Peterson wrote: I've seen people change their Bugzilla name to include a comment about being on PTO. We should promote this practice. We could also add a Bugzilla feature (just a simple check box or a PTO date range) that

Re: review stop-energy (was 24hour review)

On 09/07/2013 21:29, Chris Peterson wrote: I really wish Bugzilla could let me flag myself as not available for reviews when I'm on vacation, say. Expecting people to comment about being on vacation while on vacation is, imo, not reasonable. I've seen people change their Bugzilla name to

Re: Bug 851818 - Modernizing the Enter Bug Entry Page in Bugzilla

On 18/03/2013 16:27, Jason Smith wrote: - BootToGecko - Big focus at Mozilla with a lot of people working on this project, so I think this could benefit greatly from being on the front page. This should be Firefox OS as that's what the users will know it as. *Rationale for Removals* -