Re: Proposed W3C Charter: Second Screen Working Group

[Tantek Çelik]

This is an improvement and I think has a better chance of effecting
change with the specific proposals.

We're still making this an FO right? (I think we should)

perhaps:

s/We would ask that:/We ask (formal objection) that:

Your "open to other paths" closing statement provides an out to
resolving the FO without necessarily doing everything we precisely
ask, which both helps the dialog, and allows us room to declare the FO
upfront.

Thanks,

Tantek

On Fri, Jan 5, 2018 at 12:58 PM, L. David Baron  wrote:
> So after a little off-list discussion with SC, I have a somewhat
> revised proposal for comments that perhaps proposes what might be a
> more acceptable remedy (although thanks to timezones I don't
> actually know what SC thinks of this proposal).
>
> -David
>
> =
>
> The current situation with the API developed by this Working Group
> is that it is a API for a web page to interact with a connection
> between the web browser and a separate screen that exists entirely
> in a closed ecosystem.  For example, a browser made by Google might
> connect to displays that support the proprietary Chromecast
> protocol, whereas one made by Apple might connect to displays that
> support the proprietary AirPlay protocol.
>
> We know that parts of an Open Screen Protocol are in an early stage
> of development at https://github.com/webscreens/openscreenprotocol
> (as linked from the charter), and the goal of this work is to
> improve on this situation.  We hope it will allow for interoperable
> discovery of, identification of, and communication with presentation
> displays.
>
> However, we're deeply concerned about chartering a second iteration
> of the work that continues building the Presentation API on top of a
> closed ecosystem, when the work to make the ecosystem more open
> appears to have a lower priority.  While we understand that the work
> on building an open ecosystem still requires incubation, we believe
> it should have the highest priority in this space.
>
> We would ask that:
>
>  * the charter be clearer that modifications to the current CR-level
>specs that are needed to achieve interoperability are expected
>(rather than saying "This Working Group does not anticipate
>further changes to this specification."),
>
>  * the charter be clearer that building an open system that allows
>multiple browsers to interact with multiple displays is a
>requirement for the specifications advancing to Proposed
>Recommendation and to Recommendation, and
>
>  * work on a second level of the presentation API remain in
>incubation (and not yet be added to this charter) until after the
>work to build an open protocol moves from incubation into
>standardization,
>
> although we are open to other paths toward fixing this situation.
>
>
> On Friday 2018-01-05 09:36 -0700, Peter Saint-Andre wrote:
>> Agreed. Thanks for the careful wording, David! (BTW s/apple/Apple/)
>>
>> On 1/5/18 9:08 AM, Eric Rescorla wrote:
>> > LGTM!
>> >
>> > On Thu, Jan 4, 2018 at 9:56 PM, L. David Baron  wrote:
>> > >
>> > > So I think Martin, Peter, and I share similar concerns here, and I'm
>> > > inclined to turn those concerns into an objection to this charter.
>> > >
>> > > So how does this sound for proposed comments on the charter
>> > > (submitted as a formal objection)?  Note that I've tried to turn the
>> > > comments into a specific suggestion for a remedy, but I'm far from
>> > > sure if that suggestion is the right one.
>> > >
>> > > I've avoided mentioning the comment about "further changes" in the
>> > > specs that the existing working group has in CR, to avoid
>> > > distracting from what I think is the main piece.  But let me know if
>> > > you see a good way to work it in.
>> > >
>> > > But I'd be particularly interested to hear if SC thinks this might
>> > > be harmful rather than helpful to the end goal for some reason, or
>> > > if he has other disagreements with this approach, or better
>> > > suggestions for what remedy we should suggest.
>> > >
>> > > -David
>> > >
>> > > =
>> > >
>> > > The current situation with the API developed by this Working Group
>> > > is that it is a API for a web page to interact with a connection
>> > > between the web browser and a separate screen that exists entirely
>> > > in a closed ecosystem.  For example, a browser made by Google might
>> > > connect to displays that support the proprietary Chromecast
>> > > protocol, whereas one made by apple might connect to displays that
>> > > support the proprietary AirPlay protocol.
>> > >
>> > > We know that parts of an Open Screen Protocol are in an early stage
>> > > of development at https://github.com/webscreens/openscreenprotocol
>> > > (as linked from the charter), and the goal of this work is to
>> > > improve on this situation.  We hope it will allow for interoperable
>> > > discovery of, identification of, and communication with presentation
>> > > displays.  

Re: Proposed W3C Charter: Second Screen Working Group

[Peter Saint-Andre]

Looks good. Thanks, David!

On 1/5/18 1:58 PM, L. David Baron wrote:
> So after a little off-list discussion with SC, I have a somewhat
> revised proposal for comments that perhaps proposes what might be a
> more acceptable remedy (although thanks to timezones I don't
> actually know what SC thinks of this proposal).
> 
> -David
> 
> =
> 
> The current situation with the API developed by this Working Group
> is that it is a API for a web page to interact with a connection
> between the web browser and a separate screen that exists entirely
> in a closed ecosystem.  For example, a browser made by Google might
> connect to displays that support the proprietary Chromecast
> protocol, whereas one made by Apple might connect to displays that
> support the proprietary AirPlay protocol.
> 
> We know that parts of an Open Screen Protocol are in an early stage
> of development at https://github.com/webscreens/openscreenprotocol
> (as linked from the charter), and the goal of this work is to
> improve on this situation.  We hope it will allow for interoperable
> discovery of, identification of, and communication with presentation
> displays.
> 
> However, we're deeply concerned about chartering a second iteration
> of the work that continues building the Presentation API on top of a
> closed ecosystem, when the work to make the ecosystem more open
> appears to have a lower priority.  While we understand that the work
> on building an open ecosystem still requires incubation, we believe
> it should have the highest priority in this space.
> 
> We would ask that:
> 
>  * the charter be clearer that modifications to the current CR-level
>specs that are needed to achieve interoperability are expected
>(rather than saying "This Working Group does not anticipate
>further changes to this specification."),
> 
>  * the charter be clearer that building an open system that allows
>multiple browsers to interact with multiple displays is a
>requirement for the specifications advancing to Proposed
>Recommendation and to Recommendation, and
> 
>  * work on a second level of the presentation API remain in
>incubation (and not yet be added to this charter) until after the
>work to build an open protocol moves from incubation into
>standardization,
> 
> although we are open to other paths toward fixing this situation.
> 
> 
> On Friday 2018-01-05 09:36 -0700, Peter Saint-Andre wrote:
>> Agreed. Thanks for the careful wording, David! (BTW s/apple/Apple/)
>>
>> On 1/5/18 9:08 AM, Eric Rescorla wrote:
>>> LGTM!
>>>
>>> On Thu, Jan 4, 2018 at 9:56 PM, L. David Baron  wrote:

 So I think Martin, Peter, and I share similar concerns here, and I'm
 inclined to turn those concerns into an objection to this charter.

 So how does this sound for proposed comments on the charter
 (submitted as a formal objection)?  Note that I've tried to turn the
 comments into a specific suggestion for a remedy, but I'm far from
 sure if that suggestion is the right one.

 I've avoided mentioning the comment about "further changes" in the
 specs that the existing working group has in CR, to avoid
 distracting from what I think is the main piece.  But let me know if
 you see a good way to work it in.

 But I'd be particularly interested to hear if SC thinks this might
 be harmful rather than helpful to the end goal for some reason, or
 if he has other disagreements with this approach, or better
 suggestions for what remedy we should suggest.

 -David

 =

 The current situation with the API developed by this Working Group
 is that it is a API for a web page to interact with a connection
 between the web browser and a separate screen that exists entirely
 in a closed ecosystem.  For example, a browser made by Google might
 connect to displays that support the proprietary Chromecast
 protocol, whereas one made by apple might connect to displays that
 support the proprietary AirPlay protocol.

 We know that parts of an Open Screen Protocol are in an early stage
 of development at https://github.com/webscreens/openscreenprotocol
 (as linked from the charter), and the goal of this work is to
 improve on this situation.  We hope it will allow for interoperable
 discovery of, identification of, and communication with presentation
 displays.  However, we're deeply concerned about chartering a second
 iteration of the work that continues building the Presentation API
 on top of a closed ecosystem, when the work to make the ecosystem
 more open has a lower priority.  While we understand that the work
 on building an open ecosystem still requires incubation, we believe
 it should have the highest priority in this space.  We believe that
 rechartering the Second Screen WG should wait until that work is
 ready to be in a working group, 

Re: Proposed W3C Charter: Second Screen Working Group

[L. David Baron]

So after a little off-list discussion with SC, I have a somewhat
revised proposal for comments that perhaps proposes what might be a
more acceptable remedy (although thanks to timezones I don't
actually know what SC thinks of this proposal).

-David

=

The current situation with the API developed by this Working Group
is that it is a API for a web page to interact with a connection
between the web browser and a separate screen that exists entirely
in a closed ecosystem.  For example, a browser made by Google might
connect to displays that support the proprietary Chromecast
protocol, whereas one made by Apple might connect to displays that
support the proprietary AirPlay protocol.

We know that parts of an Open Screen Protocol are in an early stage
of development at https://github.com/webscreens/openscreenprotocol
(as linked from the charter), and the goal of this work is to
improve on this situation.  We hope it will allow for interoperable
discovery of, identification of, and communication with presentation
displays.

However, we're deeply concerned about chartering a second iteration
of the work that continues building the Presentation API on top of a
closed ecosystem, when the work to make the ecosystem more open
appears to have a lower priority.  While we understand that the work
on building an open ecosystem still requires incubation, we believe
it should have the highest priority in this space.

We would ask that:

 * the charter be clearer that modifications to the current CR-level
   specs that are needed to achieve interoperability are expected
   (rather than saying "This Working Group does not anticipate
   further changes to this specification."),

 * the charter be clearer that building an open system that allows
   multiple browsers to interact with multiple displays is a
   requirement for the specifications advancing to Proposed
   Recommendation and to Recommendation, and

 * work on a second level of the presentation API remain in
   incubation (and not yet be added to this charter) until after the
   work to build an open protocol moves from incubation into
   standardization,

although we are open to other paths toward fixing this situation.


On Friday 2018-01-05 09:36 -0700, Peter Saint-Andre wrote:
> Agreed. Thanks for the careful wording, David! (BTW s/apple/Apple/)
> 
> On 1/5/18 9:08 AM, Eric Rescorla wrote:
> > LGTM!
> > 
> > On Thu, Jan 4, 2018 at 9:56 PM, L. David Baron  wrote:
> > >
> > > So I think Martin, Peter, and I share similar concerns here, and I'm
> > > inclined to turn those concerns into an objection to this charter.
> > >
> > > So how does this sound for proposed comments on the charter
> > > (submitted as a formal objection)?  Note that I've tried to turn the
> > > comments into a specific suggestion for a remedy, but I'm far from
> > > sure if that suggestion is the right one.
> > >
> > > I've avoided mentioning the comment about "further changes" in the
> > > specs that the existing working group has in CR, to avoid
> > > distracting from what I think is the main piece.  But let me know if
> > > you see a good way to work it in.
> > >
> > > But I'd be particularly interested to hear if SC thinks this might
> > > be harmful rather than helpful to the end goal for some reason, or
> > > if he has other disagreements with this approach, or better
> > > suggestions for what remedy we should suggest.
> > >
> > > -David
> > >
> > > =
> > >
> > > The current situation with the API developed by this Working Group
> > > is that it is a API for a web page to interact with a connection
> > > between the web browser and a separate screen that exists entirely
> > > in a closed ecosystem.  For example, a browser made by Google might
> > > connect to displays that support the proprietary Chromecast
> > > protocol, whereas one made by apple might connect to displays that
> > > support the proprietary AirPlay protocol.
> > >
> > > We know that parts of an Open Screen Protocol are in an early stage
> > > of development at https://github.com/webscreens/openscreenprotocol
> > > (as linked from the charter), and the goal of this work is to
> > > improve on this situation.  We hope it will allow for interoperable
> > > discovery of, identification of, and communication with presentation
> > > displays.  However, we're deeply concerned about chartering a second
> > > iteration of the work that continues building the Presentation API
> > > on top of a closed ecosystem, when the work to make the ecosystem
> > > more open has a lower priority.  While we understand that the work
> > > on building an open ecosystem still requires incubation, we believe
> > > it should have the highest priority in this space.  We believe that
> > > rechartering the Second Screen WG should wait until that work is
> > > ready to be in a working group, and that advancing the current
> > > specifications (developed under the existing charter) to Proposed
> > > Recommendation probably 

Re: Announcing the next Extended Support Release of Firefox - ESR60 with policy engine

[Gijs Kruitbosch]

On 04/01/2018 18:06, Tom Ritter wrote:

I am curious what Enterprise users are asking for.  I'd like to
think/hope that a primary concern of enterprise is "Security" (or the
separate topic of Privacy); but I'm not certain it is.

In particular, I am curious if enterprise users would be interested in
flipping preferences that would provide stronger security isolation at
the cost of more resources (like process/memory).  This is basically
what Chrome is providing with command-line flags for site isolation. A
company can decide that domains of their choosing get allocated into
per-origin processes, at the potential cost of a bunch of additional
processes.


Yes, in fact this (process-per-site) has specifically already come up on 
the enterprise list in the last few days.


~ Gijs



-tom

On Thu, Dec 21, 2017 at 10:09 AM, Mike Kaply  wrote:

We currently do not plan to allow arbitrary preferences, but if certain
preferences are important, we can add policies for them.

We could also add policies that set groups of preferences for specific
purposes.

Mike

On Thu, Dec 21, 2017 at 10:03 AM, Luke Crouch  wrote:


On Wednesday, December 20, 2017 at 9:42:50 AM UTC-6, Sylvestre Ledru wrote:

First, as Dave Camp mentioned during the Firefox All Hands, we are

started some developments to improve

our support for enterprise users.
More information can be found on the wiki: https://wiki.mozilla.org/

Firefox/EnterprisePolicies

The first example configuration.json I saw on the page only shows some
custom policy configs - e.g., bookmarks_on_toolbar, allow_popups_from, etc.

Will the policy config allow admins to set other/any about:config prefs to
custom values?

I'm thinking specifically it would be cool to let Enterprise+InfoSec
admins set some security + privacy about:config prefs to more hardened
defaults.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposed W3C Charter: Second Screen Working Group

[Peter Saint-Andre]

Agreed. Thanks for the careful wording, David! (BTW s/apple/Apple/)

On 1/5/18 9:08 AM, Eric Rescorla wrote:
> LGTM!
> 
> On Thu, Jan 4, 2018 at 9:56 PM, L. David Baron  > wrote:
> 
> So I think Martin, Peter, and I share similar concerns here, and I'm
> inclined to turn those concerns into an objection to this charter.
> 
> So how does this sound for proposed comments on the charter
> (submitted as a formal objection)?  Note that I've tried to turn the
> comments into a specific suggestion for a remedy, but I'm far from
> sure if that suggestion is the right one.
> 
> I've avoided mentioning the comment about "further changes" in the
> specs that the existing working group has in CR, to avoid
> distracting from what I think is the main piece.  But let me know if
> you see a good way to work it in.
> 
> But I'd be particularly interested to hear if SC thinks this might
> be harmful rather than helpful to the end goal for some reason, or
> if he has other disagreements with this approach, or better
> suggestions for what remedy we should suggest.
> 
> -David
> 
> =
> 
> The current situation with the API developed by this Working Group
> is that it is a API for a web page to interact with a connection
> between the web browser and a separate screen that exists entirely
> in a closed ecosystem.  For example, a browser made by Google might
> connect to displays that support the proprietary Chromecast
> protocol, whereas one made by apple might connect to displays that
> support the proprietary AirPlay protocol.
> 
> We know that parts of an Open Screen Protocol are in an early stage
> of development at https://github.com/webscreens/openscreenprotocol
> 
> (as linked from the charter), and the goal of this work is to
> improve on this situation.  We hope it will allow for interoperable
> discovery of, identification of, and communication with presentation
> displays.  However, we're deeply concerned about chartering a second
> iteration of the work that continues building the Presentation API
> on top of a closed ecosystem, when the work to make the ecosystem
> more open has a lower priority.  While we understand that the work
> on building an open ecosystem still requires incubation, we believe
> it should have the highest priority in this space.  We believe that
> rechartering the Second Screen WG should wait until that work is
> ready to be in a working group, and that advancing the current
> specifications (developed under the existing charter) to Proposed
> Recommendation probably depends on this new work in order to
> demonstrate real interoperability, although we are open to other
> paths toward fixing this situation.
> 
> 
> On Thursday 2018-01-04 09:29 -0700, Peter Saint-Andre wrote:
> > +1 to Martin's feedback.
> >
> > On 1/3/18 10:19 PM, Martin Thomson wrote:
> > > Without the protocol pieces, this remains vendor-specific.  We
> should
> > > comment on this and make it clear that we think that definition of a
> > > generic protocol for interacting with the second display has not
> been
> > > given sufficient priority.  Allowing this to proceed without a
> generic
> > > protocol would be bad for the ecosystem.
> > >
> > > From what I can see, there seem to be a bunch of options that are
> > > described for the protocol, without extremely scant detail. 
> Certainly
> > > not enough to implement anything.
> > >
> > > I'm concerned with the statement "This Working Group does not
> > > anticipate further changes to this specification" regarding the
> > > presentation API.  I haven't reviewed this thoroughly, but there
> > > appear to be some gaps in rather fundamental pieces.  For instance -
> > > and maybe this doesn't change the API at all - but the means of
> > > identification for screens is unclear.  Some of these details are
> > > important, such as whether knowledge of a presentation URL is
> all the
> > > information necessary to use that URL (i.e., are they capability
> > > URLs?).
> > >
> > > On Thu, Jan 4, 2018 at 2:31 PM, Shih-Chiang Chien
> > wrote:
> > >> The SecondScreen WG intended to move the protocol development
> to CG, and
> > >> will possibly move to IETF after the incubation phase.
> > >> The revised charter is trying to associate the work of CG to
> the timeline
> > >> of Presentation API development.
> > >>
> > >> At the meantime, WG will tackle the testability issue found
> while creating
> > >> test cases and cultivating Level 2 API requirements for
> advanced use cases.
> > >>
> > >> I'll vote to 

Re: Proposed W3C Charter: Second Screen Working Group

[Eric Rescorla]

LGTM!

On Thu, Jan 4, 2018 at 9:56 PM, L. David Baron  wrote:

> So I think Martin, Peter, and I share similar concerns here, and I'm
> inclined to turn those concerns into an objection to this charter.
>
> So how does this sound for proposed comments on the charter
> (submitted as a formal objection)?  Note that I've tried to turn the
> comments into a specific suggestion for a remedy, but I'm far from
> sure if that suggestion is the right one.
>
> I've avoided mentioning the comment about "further changes" in the
> specs that the existing working group has in CR, to avoid
> distracting from what I think is the main piece.  But let me know if
> you see a good way to work it in.
>
> But I'd be particularly interested to hear if SC thinks this might
> be harmful rather than helpful to the end goal for some reason, or
> if he has other disagreements with this approach, or better
> suggestions for what remedy we should suggest.
>
> -David
>
> =
>
> The current situation with the API developed by this Working Group
> is that it is a API for a web page to interact with a connection
> between the web browser and a separate screen that exists entirely
> in a closed ecosystem.  For example, a browser made by Google might
> connect to displays that support the proprietary Chromecast
> protocol, whereas one made by apple might connect to displays that
> support the proprietary AirPlay protocol.
>
> We know that parts of an Open Screen Protocol are in an early stage
> of development at https://github.com/webscreens/openscreenprotocol
> (as linked from the charter), and the goal of this work is to
> improve on this situation.  We hope it will allow for interoperable
> discovery of, identification of, and communication with presentation
> displays.  However, we're deeply concerned about chartering a second
> iteration of the work that continues building the Presentation API
> on top of a closed ecosystem, when the work to make the ecosystem
> more open has a lower priority.  While we understand that the work
> on building an open ecosystem still requires incubation, we believe
> it should have the highest priority in this space.  We believe that
> rechartering the Second Screen WG should wait until that work is
> ready to be in a working group, and that advancing the current
> specifications (developed under the existing charter) to Proposed
> Recommendation probably depends on this new work in order to
> demonstrate real interoperability, although we are open to other
> paths toward fixing this situation.
>
>
> On Thursday 2018-01-04 09:29 -0700, Peter Saint-Andre wrote:
> > +1 to Martin's feedback.
> >
> > On 1/3/18 10:19 PM, Martin Thomson wrote:
> > > Without the protocol pieces, this remains vendor-specific.  We should
> > > comment on this and make it clear that we think that definition of a
> > > generic protocol for interacting with the second display has not been
> > > given sufficient priority.  Allowing this to proceed without a generic
> > > protocol would be bad for the ecosystem.
> > >
> > > From what I can see, there seem to be a bunch of options that are
> > > described for the protocol, without extremely scant detail.  Certainly
> > > not enough to implement anything.
> > >
> > > I'm concerned with the statement "This Working Group does not
> > > anticipate further changes to this specification" regarding the
> > > presentation API.  I haven't reviewed this thoroughly, but there
> > > appear to be some gaps in rather fundamental pieces.  For instance -
> > > and maybe this doesn't change the API at all - but the means of
> > > identification for screens is unclear.  Some of these details are
> > > important, such as whether knowledge of a presentation URL is all the
> > > information necessary to use that URL (i.e., are they capability
> > > URLs?).
> > >
> > > On Thu, Jan 4, 2018 at 2:31 PM, Shih-Chiang Chien 
> wrote:
> > >> The SecondScreen WG intended to move the protocol development to CG,
> and
> > >> will possibly move to IETF after the incubation phase.
> > >> The revised charter is trying to associate the work of CG to the
> timeline
> > >> of Presentation API development.
> > >>
> > >> At the meantime, WG will tackle the testability issue found while
> creating
> > >> test cases and cultivating Level 2 API requirements for advanced use
> cases.
> > >>
> > >> I'll vote to support this revised charter.
> > >>
> > >> Best Regards,
> > >> Shih-Chiang Chien
> > >> Mozilla Taiwan
> > >>
> > >> On Thu, Jan 4, 2018 at 10:08 AM, L. David Baron 
> wrote:
> > >>
> > >>> The W3C is proposing a revised charter for:
> > >>>
> > >>>   Second Screen Working Group
> > >>>   https://w3c.github.io/secondscreen-charter/
> > >>>   https://lists.w3.org/Archives/Public/public-new-work/
> 2017Dec/.html
> > >>>
> > >>> Mozilla has the opportunity to send comments or objections through
> > >>> Friday, January 52.  (Sorry for failing to send this out 

Re: overly strict eslint rules

[Andrew Halberstadt]

Not replying to anyone specifically, but Sylvestre's team is working on
getting our linters hooked up to mozreview/phabricator as well. I think
this paired with bootstrapping the hooks will smooth out the lint fixing
workflow considerably.

Andrew


On Fri, Jan 5, 2018 at 5:58 AM Mark Banner  wrote:

> 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 directory
> >> Clobbering node_modules...
> >> Installing eslint for mach using
> >> "d:\mozilla-build\node-v8.1.4-win-x64\npm.cmd install
> >> --loglevel=error"...
> >> npm ERR! code ENOLOCAL
> >> npm ERR! Could not install from
> >> "tools\lint\eslint\eslint-plugin-mozilla" as it does not contain a
> >> package.json file.
> > In this case, I think it incorrectly removed the
> > tools\lint\eslint\eslint-plugin-mozilla directory, if you check your
> > source tree diffs, you should see if that was the case or not (though
> > since this was a while ago, you may have already found that by now).
> >
> > I've a feeling I know why, unfortunately my windows environment isn't
> > very good at the moment, so I'll need to get that updated to investigate.
> Just to follow up on this, this was a one-off issue due to a bad clobber
> when we attempted to update from v3 to v4 of ESLint. I've tracked down
> the issue , and
> I'm near to a patch.
>
> The workaround is running a revert on tools/lint/eslint/ and then
> running eslint again - though I suspect as we did the upgrade a while
> ago, most people will have already fixed this themselves.
>
> Mark.
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: overly strict eslint rules

[Mark Banner]

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 directory
Clobbering node_modules...
Installing eslint for mach using
"d:\mozilla-build\node-v8.1.4-win-x64\npm.cmd install 
--loglevel=error"...

npm ERR! code ENOLOCAL
npm ERR! Could not install from
"tools\lint\eslint\eslint-plugin-mozilla" as it does not contain a
package.json file.
In this case, I think it incorrectly removed the 
tools\lint\eslint\eslint-plugin-mozilla directory, if you check your 
source tree diffs, you should see if that was the case or not (though 
since this was a while ago, you may have already found that by now).


I've a feeling I know why, unfortunately my windows environment isn't 
very good at the moment, so I'll need to get that updated to investigate.
Just to follow up on this, this was a one-off issue due to a bad clobber 
when we attempted to update from v3 to v4 of ESLint. I've tracked down 
the issue , and 
I'm near to a patch.


The workaround is running a revert on tools/lint/eslint/ and then 
running eslint again - though I suspect as we did the upgrade a while 
ago, most people will have already fixed this themselves.


Mark.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform