A file from one of my extensions has been copied, so that three of them now share a common code file. (It's for accessing managed storage, with a fallback).
Keeping this updated to all extensions by copying is a bit tedious, as changes to one are not automatically applied to the other.
What is a clean way to use the same .js file in several web extensions?
I think the good approach is to publish your file as an npm package, use it as a dependency and update in other extensions using greenkeeper. So then you can build extensions via any Continuous Integration (CI) service and even upload it using Chrome Webstore API
Related
Is there any standard/conventional way (package/library, pattern, etc.) to serve the latest version of some static files from a given git repository in Node.js?
My idea so far is to clone the repository at npm start and take the files that I need from there, and to provide a webhook to be called when the repository receives a commit, to then pull the changes so that the files get updated even when the app is running.
This seems like it could work, but I do not want to reinvent the wheel, if it already exists. If there is a method that is already relatively well known, a conventional pattern or a package that already does this, it would be wise to use it and not bother with implementing the details, fixing security vulnerabilities and keeping it up to date.
Also, while we are on it, are there reasons why I should not do this in the first place?
Edit:
I should probably give an explanation on why I would want to do this.
I basically have a web app (nothing too complex, a few routes here and there), let's call it example.com, and a few "self contained sites" (i.e. collections of static files that for all intents and purposes could live independently of the main website and each other).
I could put them each on their sub-domain, but that would probably mean using more app instances and time for just serving some static files, so I want to serve these "sub-websites" on their own paths on that app, like example.com/sub-site1, example.com/sub-site2, etc., from the same app instance as the main example.com, as to not incur higher hosting cost.
I could also modify those static websites to wrap them in Node.js packages and install the packages in the main app, but I want to keep them clean, simple, static files, agnostic of the platform they are being served from.
That leaves me with the option of moving a bunch of files to the main app, but I do not want to manually restart the app each time any one of those sites gets updated, or even worse, manually update the repository of the main app with the new versions of the static files.
Is there any standard/conventional way (package/library, pattern, etc.) to serve the latest version of some static files from a given git repository in Node.js?
There is no standard for this kind of task. The best way is to use the official Github SDK since there is a getContent method for this purpose.
Also, while we are on it, are there reasons why I should not do this in the first place?
A Github repository can be deleted, but an npm package cannot (there is a unpublish policy for this reason).
I don't know your use cases, but those files are critical for your application?
If so, it is risky to depends like this on an ephemeral repository: you could just fork and keep the fork up-to-date with a Github action
How can I share components across multiple react projects without having to publish them on a public package manager like NPM?
Option 1: You can use npm and use private packages so they're not external facing. There are also artifactories and scoped packages that usually represent company-wide projects that can be public or private. See https://docs.npmjs.com/private-modules/intro and https://docs.npmjs.com/misc/scope.
Option 2: Essentially, you can develop projects with a flattened structure. You can then import various projects and/or components into other projects or folders. This is entirely dependent on your codebase and configuration. With this model though, a lot of times publishing to npm comes fairly naturally since each folder may be its own project with its own package.json.
Updated:
Option 3: Bit focuses on the composability of components from everything from the little things like a button to the actual view and app itself—each target is its own package. Overall, it's an opinionated, yet customizable framework that can enable quicker development, managed dependencies, and organized code.
Option 4: RushJS is a monorepo manager built by Microsoft that allows for flexibility of different kinds of apps and services utilizing pnpm underneath (as opposed to yarn and npm), which alleviates problems that stem from dependency issues.
Check out Bit:
Bit is an open-source cli tool for collaborating on isolated components across projects and repositories. Use Bit to distribute discrete components from a design library or a project into a standalone reusable package and utilize it across applications.
You could also upload them to a private git repo such a Github and then pull them in from there.
Ryanve has a nice example over here: https://stackoverflow.com/a/28729646/1592783
You could create a repo of shared components and then have your Node.js start script call a shell script to do a git pull from that repo and the move the shared components from that directory to your project's directory. That way, every time you call run 'npm start' you will have the latest version of the shared components loaded into your project
We have a list of browsers we test our webapp in. I have a task to notify the user if his browser isn't supported or tested to work well with our app.
We have a browserslist configuration in the project and I'm looking for a way to test current browser against the list.
I tried browserlist-useragent but we can't compile it with webpack due to the fact it uses net, fs, tls and other native node modules we don't want to include in our bundle.
Is there any better way do avoid copying the list of supported browsers in many different places and just use browserlist configuration that already exists to detect if user uses supported one or not?
I'd consider using this "utility" package https://github.com/browserslist/browserslist-useragent-regexp in the project that uses browserslist, and then use the file generated by the script suggested by this package to then use anywhere else.
In reality, all you want is the regex in the generated file. This can be placed in any client or server code you need for browser detection. I've placed mine in some classic asp.
Also note that on a Windows PC, the instructions provided don't result in a file containing a RegEx. Instead, you'd need to run npx browserslist-useragent-regexp --allowHigherVersions to display a suitable RegEx on your console, and then add that where needed.
In separate Windows 8.1/Windows Phone 8.1 projects, including the SharpDX.targets file from the SharpDX repo includes all of its content build actions in each project. Doing the same in the shared project in a universal app doesn't work (project reloads successfully but tools are no in the Build Action list).
Is there an alternate solution to keeping the content in the shared project rather than keeping copies in each of the W8.1/WP8.1 projects just because there is no centralized way of building it?
No, a shared project in a universal app is never really built. It's merely a container of files to be shared into each of the specific projects. If you have custom build actions, you need to include them in each specific project (that requires them).
I'm currently using Visual Studio Web Essentials in order to bundle and minify my CSS and JavaScript files.
At present I'm manually creating the bundles with a version number (e.g. mybundle-1.0.0.css) in order to avoid caching issues when pushed out to production. I'm also having to manually change the bundle files version number each time a change is made to the source.
Is there any sort of automatic versioning functionality in Web Essentials bundling that I may have overlooked?
The ideal workflow would be:
Developer updates a source file.
Web essentials updates the bundle automatically.
Web essentials increments the version number in the filename automatically.
Is this possible?
If not, I'd be happy to hear any suggestions for better developer workflows.
Web Essentials doesn't have any support for dynamic versioning. Instead, I always use a dynamic runtime feature to automatically append fingerprints to my JS and CSS references. This works better for me, because it is completely independent of any build process or tooling support, instead it just looks at the actual files for changes. So it's much more robust.
I just wrote it up in a blog post here