How to deal with our (currently) duplicated files?

[Patrick Brosset]

Hi folks,


Honza and I just had a long meeting where we tried to evaluate the current
situation related to some of our files being duplicated.


*Here's the situation:*


The debugger tool can run in 2 environments: either within the toolbox, as
a panel, or as a web page, independently of the toolbox (both in Chrome and
Firefox by the way).

The latter is what active contributors to the project use the most because
it's so great to make changes to the debugger this way.


The netmonitor is wanting to do the same. Ricky and Fred are working hard
to have launchpad support for this panel too, without moving to GitHub
though, directly within m-c, like we did for the inspector end of last year.


What having 2 environments means however is that you need all dependencies
to be available in both environments. And some of them are shared with
other tools that are in m-c.

So, when running as a web page, you need to get some dependencies from an
npm module somewhere, but when running inside the toolbox, those same
dependencies are actually packaged within Firefox, because other DevTools
things need them too.


Right now, we have code duplicated between m-c and the devtools-core repo
<http://github.com/devtools-html/devtools-core>.

Honza created a list of the duplicated files
<https://docs.google.com/document/d/17VX8T1QyfhAfLa9vSLSNEpzinvl6nZEbVq5KhqkHwDk/edit#>
.


As you can see in the list, some files have diverged quite a lot.

The most problematic one being the splitter component. It got maintained in
both locations, and is now very different in each of them.

This is a trend that is starting to appear for other files too.


We have to stop this now, and should have our files in just one location.


*How do we fix it:*


This is where I need your opinions and help.


One option would be to do what we do with the reps repo on GitHub
<https://github.com/devtools-html/reps>: make the devtools-core repository
the source of truth, publish it to npm as well as bundle it and land it in
m-c on a regular basis.


Alternatively: kill devtools-core (at least the parts that are duplicated),
and use the code that is in m-c instead. Publishing to npm from there
instead.

When running in launchpad, the netmonitor would be able to npm link to
those dependencies.


Are there other solutions?

Ideally, I want to minimize the number of steps one has to take when making
a change in some shared code.


Whatever we choose, we're going to need people to reconcile these files
and, for some files, it's not going to be easy. We might want to focus
first on the things that are used in just a few places only, and that have
not diverged much, to simplify the first steps.


Thanks,
Patrick

[Patrick Brosset]

Related to this: would anyone complain if we removed the console.html
repository? All the console work happens in m-c, not in GitHub, and it
looks like this repo requires some stuff in devtools-core that are not used
by anything else. So removing console.html would clean a few of these
things.


On Tue, Apr 11, 2017 at 12:09 PM, Patrick Brosset <pbro...@mozilla.com>
wrote:

[Jason Laster]

We can safely take console.html out of the devtools-html org and remove its
dependencies in devtools-core. That will remove several files

On Tue, Apr 11, 2017 at 6:15 AM, Patrick Brosset <pbro...@mozilla.com>
wrote:

> _______________________________________________
> dev-developer-tools mailing list
> dev-devel...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-developer-tools
>

[Patrick Brosset]

Jason and I had a chat about this, here's a quick summary so that everyone
knows:

My solution 2: getting rid of certain devtools-core things and putting them
in m-c and publishing them to npm from there would be detrimental to the
current debugger project. It would change a lot this project's current
processes for the worse.
Right now, the debugger bundles its dependencies when it lands in m-c.

There are 2 other solutions to be added to the list though:
3) if we wait until the rest of DevTools is in GitHub, it might make it
easier to consume npm modules from there
4) or, make it possible to consume npm modules in m-c directly, so the
shared things would remain in devtools-core, and be published in npm, and
we would just get them in m-c.

On top of these, there are 2 specific cases:
- things that only console.html needs: as seen in previous emails, we can
safely get rid of those
- things that only the netmonitor launchpad support requires (like the tree
table widget, or file-saver, etc.): these things could stay in m-c, and
have their own package.json file so they can also be published to npm from
there, so that when the netmonitor runs via launchpad, it can uses those as
dependencies.

I hope this makes sense.

[Fred Lin]

I agree with pattrick, at first time when we made the prove of concept
version to make Networkmonitor run on the browser, we test it in separate
project, so all dependency files are required to be out of m-c. Now we can
run Networkmonitor in m-c and have enough experience to revisit if we can
do better on file duplicating issue.


Here is the suggest approach to reduce maintenance in 2 places
(devtools-core and m-c), mainly related to netmonitor

- If the module/file is used in debugger.html, we will use webpack alias
(ex: context menu), those files are necessary for debugger.html so we
should not move them back to m-c at this moment
- Review netmonitor related patches to devtools-core
<https://github.com/devtools-html/devtools-core/pull/291/files>


- ex: https://github.com/devtools-html/devtools-core/pull/291,
https://github.com/devtools-html/devtools-core/pull/290
<https://github.com/devtools-html/devtools-core/pull/291/files>


-

We will remove and use webpack alias if the patch in devtools-core
only contains some path change
- We will move mock/shim used only by netmonitor back to
`netmonitor/src/utils/shim`
- Since we can use webpack alias to point file path in m-c, added a
package.json file in m-c to publish those things to npm are not necessary

I can imagine only a few files will still live in devtools-core. For longer
term about shared components in devtools-core (tree, tab, that only used by
netmonitor now), I think it might worth to keep them in `devtools-core`
instead of put a separate launchpad compatible version in
`m-c/client/shared/components`, devtools-core should be the place that
developers could found all shared components among Devtools. Extension
developers can reuse those components to build their panel extensions.


regards
--
Fred

2017-04-11 22:37 GMT+08:00 Patrick Brosset <pbro...@mozilla.com>:

> Hi folks!
>
> So I went through some of the modules from Honza's doc:
> https://docs.google.com/document/d/17VX8T1QyfhAfLa9vSLSNEpzi
> nvl6nZEbVq5KhqkHwDk/edit#
> There might be more than this, but so far, the ones that I found are only
> used in m-c are:
> - the tree table widget (client/shared/components/tree)
> - search-box (client/shared/components/search-box)
> - stack-trace (client/shared/components/stack-trace)
> - Chart.js (client/shared/widgets/Chart)
> - Curl.js (client/shared/Curl)
> - File-saver.js (client/shared/File-saver)
>
> maybe others.
>
> So, maybe there's a way to prevent duplicating these specific files, as
> suggested in my last reply to the forwarded thread:
> What if we removed these things from devtools-core, just kept the ones in
> m-c, and added a package.json file in m-c to publish those things to npm,
> so that netmonitor in launchpad can use them?
>
> This would get rid of a lot of duplicated code, which would be great!
>
> Let me know how this sounds.
>
> Patrick

> --
> You received this message because you are subscribed to the Google Groups
> "Netmonitor" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to netmonitor+...@mozilla.com.
> To post to this group, send email to netmo...@mozilla.com.
> To view this discussion on the web visit https://groups.google.com/a/mo
> zilla.com/d/msgid/netmonitor/CABcuYMDQiEwXiNtprBrmbJsfkrZDnW
> OobmChsuJspLovk%3D_QUg%40mail.gmail.com
> <https://groups.google.com/a/mozilla.com/d/msgid/netmonitor/CABcuYMDQiEwXiNtprBrmbJsfkrZDnWOobmChsuJspLovk%3D_QUg%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>