Move extension content to a subfolder?

[eight04]

• Browser: Chrome
• Operating System: Windows 7 x64
• Screenshot:

Currently, we put everything in the project root. When those files are loaded as an unpacked extension, Chrome would walk through the entire file tree.

I suggest moving extension files (i.e. background/. content/, blabla.html, etc) to a subfolder (e.g. extension), so it should reduce the startup time and also simplify the build process. Note that we have to resolve all PRs first or there will be a bunch of conflicts.

[narcolepticinsomniac]

Moving our .html files to a subfolder would break practically all userstyles completely, which is why we didn't do it when we organized subfolders last time. Before that, almost every file was in the root folder, which was terrible organization-wise, but so simple I kinda miss it.

Edit: I've encouraged many authors to use broad regexp, but if I had to guess, the majority still probably don't, so it's likely still a concern.

[narcolepticinsomniac]

OTOH, I've argued before that while userstyle compatibility should be a consideration, it shouldn't prevent progress. It will break userstyles, but if you and @Mottie both still agree it's worth that trade-off, I'd be fine with that.

[Mottie]

The 126 MB you're seeing includes the database with all the installed styles. Stylus itself is about 4 MB.

If we did need to rearrange the folders, we could still keep the .html files in the root folder so no styles get broken.

[Mottie]

If you load Stylus from a git repo, the size jumps to around 64 MB because that includes the unnecessary .git & node_modules folders.

[eight04]

Moving our .html files to a subfolder would break practically all userstyles completely

I meant to move "the content of the extension itself" to a subfolder. From:

D:\Dev\stylus
├── background
├── content
├── edit
├── edit.html
├── global.css
├── images
├── install-usercss
├── install-usercss.html
├── js
├── LICENSE
├── manage
├── manage.html
├── manifest.json
├── msgbox
├── node_modules
├── options
├── options.html
├── package-lock.json
├── package.json
├── popup
├── popup.html
├── README.md
├── tools
├── vendor
├── vendor-overwrites
└── _locales

To:

D:\Dev\stylus
├── extension
|  ├── background
|  ├── content
|  ├── edit
|  ├── edit.html
|  ├── global.css
|  ├── images
|  ├── install-usercss
|  ├── install-usercss.html
|  ├── js
|  ├── manage
|  ├── manage.html
|  ├── manifest.json
|  ├── msgbox
|  ├── options
|  ├── options.html
|  ├── popup
|  ├── popup.html
|  ├── vendor
|  ├── vendor-overwrites
|  └── _locales
├── LICENSE
├── package-lock.json
├── package.json
├── README.md
└── tools
   ├── pull_locales.rb
   ├── pull_locales.sh
   ├── pull_locales_postprocess.py
   ├── remove-modules.js
   ├── update-codemirror-themes.js
   ├── update-libraries.js
   ├── update-versions.js
   └── zip.js

Hence we can load the extension folder as an unpacked extension and Chrome doesn't have to look into .git or node_modules folders. It doesn't touch the relative path between each file but the project root.

[Mottie]

Honestly, I don't see that much benefit in the change.

We're rearranging the folders just to make Chrome see less files while developing? Users testing the extension wouldn't have the .git or node_modules folder anyway. And we'd have to instruct testers to go into the extension subfolder to load the extension, or point to a file in the extension folder in the case of Firefox. I think that alone may cause more problems than it's worth in the long run.

[eight04]

Well, another solution is to upgrade my hard drive to SSD.

[tophf]

Now that the key is pinned in manifest.json we can move everything as shown in @eight04's comment above to src indeed. Not extension though.

It might cause some inconvenience to several users/collaborators who load an unpacked extension from a git-managed directory. They will have to reinstall it from src, which is trivial.

[tophf]

@eight04 fwiw here's a workaround I use - move node_modules outside and make a symlink back. I use it because reloading takes a second even on SSD and that's just plain wrong, it should reload instantly.