Coder Social home page Coder Social logo

boundation's People

Contributors

balupton avatar dependabot-preview[bot] avatar dependabot[bot] avatar github-actions[bot] avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar

Forkers

bynikesh

boundation's Issues

Your .dependabot/config.yml contained invalid details

Dependabot encountered the following error when parsing your .dependabot/config.yml:

The property '#/update_configs/0/automerged_updates/0/match/update_type' value "security" did not match one of the following values: all, security:patch, semver:patch, semver:minor, in_range

Please update the config file to conform with Dependabot's specification using our docs and online validator.

What are "best practices"?

I read in the README that it upgrades my project with best practices. I do not know from first impression if I like your best practices!
Please

  • add a best practives section in the README
  • link from the summary statement to it
  • list at least 3 of the most important best practices

Get to failed targets quicker

On typechecker:

determining engines for edition [edition-es2022]...
target:      *
passed:      6.17.1, 8.17.0, 10.24.1, 12.22.12, 14.21.3, 16.20.2, 18.18.2, 20.9.0, 21.1.0
.unique:     6.17.1, 8.17.0, 10.24.1, 12.22.12, 14.21.3, 16.20.2, 18.18.2, 20.9.0, 21.1.0
failed:      4.9.1
.unique:     4.9.1
range:       6 || 8 || 10 || 12 || 14 || 16 || 18 || 20 || 21
...determined engines for edition [edition-es2022] as [6 || 8 || 10 || 12 || 14 || 16 || 18 || 20 || 21] against [4.9.1, 6.17.1, 8.17.0, 10.24.1, 12.22.12, 14.21.3, 16.20.2, 18.18.2, 20.9.0, 21.1.0]
determining engines for edition [edition-es2021]...
target:      *
passed:      6.17.1, 8.17.0, 10.24.1, 12.22.12, 14.21.3, 16.20.2, 18.18.2, 20.9.0, 21.1.0
.unique:     
failed:      4.9.1
.unique:     4.9.1
range:       6 || 8 || 10 || 12 || 14 || 16 || 18 || 20 || 21
The edition [edition-es2021] will be trimmed, as it has no unique passing versions
determining engines for edition [edition-es2020]...
target:      *
passed:      6.17.1, 8.17.0, 10.24.1, 12.22.12, 14.21.3, 16.20.2, 18.18.2, 20.9.0, 21.1.0
.unique:     
failed:      4.9.1
.unique:     4.9.1
range:       6 || 8 || 10 || 12 || 14 || 16 || 18 || 20 || 21
The edition [edition-es2020] will be trimmed, as it has no unique passing versions
determining engines for edition [edition-es2019]...
target:      *
passed:      6.17.1, 8.17.0, 10.24.1, 12.22.12, 14.21.3, 16.20.2, 18.18.2, 20.9.0, 21.1.0
.unique:     
failed:      4.9.1
.unique:     4.9.1
range:       6 || 8 || 10 || 12 || 14 || 16 || 18 || 20 || 21
The edition [edition-es2019] will be trimmed, as it has no unique passing versions
determining engines for edition [edition-es2017]...
target:      *
passed:      6.17.1, 8.17.0, 10.24.1, 12.22.12, 14.21.3, 16.20.2, 18.18.2, 20.9.0, 21.1.0
.unique:     
failed:      4.9.1
.unique:     4.9.1
range:       6 || 8 || 10 || 12 || 14 || 16 || 18 || 20 || 21
The edition [edition-es2017] will be trimmed, as it has no unique passing versions
determining engines for edition [edition-es2016]...
target:      *
passed:      6.17.1, 8.17.0, 10.24.1, 12.22.12, 14.21.3, 16.20.2, 18.18.2, 20.9.0, 21.1.0
.unique:     
failed:      4.9.1
.unique:     4.9.1
range:       6 || 8 || 10 || 12 || 14 || 16 || 18 || 20 || 21
The edition [edition-es2016] will be trimmed, as it has no unique passing versions
determining engines for edition [edition-es2015]...
target:      *
passed:      6.17.1, 8.17.0, 10.24.1, 12.22.12, 14.21.3, 16.20.2, 18.18.2, 20.9.0, 21.1.0
.unique:     
failed:      4.9.1
.unique:     4.9.1
range:       6 || 8 || 10 || 12 || 14 || 16 || 18 || 20 || 21
The edition [edition-es2015] will be trimmed, as it has no unique passing versions
determining engines for edition [edition-es5]...
target:      *
passed:      4.9.1, 6.17.1, 8.17.0, 10.24.1, 12.22.12, 14.21.3, 16.20.2, 18.18.2, 20.9.0, 21.1.0
.unique:     4.9.1
failed:      
.unique:     
range:       4 || 6 || 8 || 10 || 12 || 14 || 16 || 18 || 20 || 21
...determined engines for edition [edition-es5] as [4 || 6 || 8 || 10 || 12 || 14 || 16 || 18 || 20 || 21] against [4.9.1, 6.17.1, 8.17.0, 10.24.1, 12.22.12, 14.21.3, 16.20.2, 18.18.2, 20.9.0, 21.1.0]
updating runtime...

As edition-es2022 covers everything but node v4, we should skip subsequent editions that don't support node v4, jumping ahead to edition-es5.

Add an option to prevent autoloader

editions and verison-range must not use the autoloader, as that will create a circular reference.

Currently autoloader is being mitigated by "targets": ["ES5"], however that means the ESM edition is also ES5, which isn't necessary.

Had some issues trying to get this to work.

➜  example boundation
file:///Users/thomas/.nvm/versions/node/v14.4.0/lib/node_modules/boundation/source/util.js:2
import typeChecker from 'typechecker'
       ^^^^^^^^^^^
SyntaxError: The requested module 'typechecker' does not provide an export named 'default'
    at ModuleJob._instantiate (internal/modules/esm/module_job.js:97:21)
    at async ModuleJob.run (internal/modules/esm/module_job.js:135:5)
    at async Loader.import (internal/modules/esm/loader.js:178:24)

'scoop update' does not update individual apps - intended?

Hi,

I have run scoop update and while it updates the list of packages it does not seem to update installed applications. I had to manually run scoop update youtube-dl for instance.

Is that an intended behavior? scoop help lists update command as: "Update apps, or Scoop itself"

provide a service to auto apply boundation updates

it would be nice if boundation.bevry.me had a service, which one could login via github into, see all their repos, sorted by those with boundation run on them last as first, and then buttons to run boundation on them

the process from here I am unsure about, but it could be something like:

  1. submit a PR with the changes boundation applied, as well as a minor version bump, and changelog entry - with the changelog entry being inside the PR description, and the changelog entry title being the title of the PR
  2. the user can then review the PR, and if all good, merge it, then create a release via github with the PR's title and description (which coincide with the changelog's)

The reason this can't be entirely automated is that travis ci has limits on how often it can be interacted with via the API, and boundation needs to set travis environment variables

don't use esm or support esm for typescript modules that still use require

also update valid-module to detect this, if it isn't already, or use valid-module for this detection

this can also be detected by actually testing the generated esm editions

package in question is https://github.com/bevry/pluginloader

the other alternative approach would be for pluginloader to use dynamic imports, however I am unsure how that converts to CJS - for plugin loader, this won't work unless there are breaking changes to the API, as dynamic imports require await, however they are occurring inside the constructor, however that is not a big deal and we can adapt

so a bit of exploration here will go far

order editions based on newest target version first

currently it works by all cjs first, then all esm first

as esm is one for all or nothing, it could be older, such as case with errlop, e.g. edition-2022, edition-2017, edition-es5, edition-2017-esm

editions autoloader doesn't support esm, to resolve this editions autoloader must be constrained to require/cjs modules, or support a esm dynamic import technique (of which node.js versions I am unsure)

here is some unfinished rewrite of the editions generate to go via newest node targets first, however it has several issues (it is dependent on targets answer order), and es versions de-duplication is tied to module technique where in this rewrite they are not

		// add edition for each babel/typescript target
		if (
			answers.compilerNode === 'babel' ||
			answers.compilerNode === 'typescript'
		) {
			// bug: es versions should be tied to import
			const esVersionsTargets = new Set()
			for (const nodeVersionTarget of answers.nodeVersionsTargeted
				.slice()
				.reverse()) {
				for (const targetModule of answers.targetModules) {
					if (targetModule === 'import') {
						if (
							!versionRange(
								nodeVersionTarget,
								'>=12', // esm
							)
						)
							continue
						if (
							answers.nodeVersionsTargetedImportRange &&
							!versionRange(
								nodeVersionTarget,
								answers.nodeVersionsTargetedImportRange,
							)
						)
							continue
					} else if (targetModule === 'require') {
						if (
							answers.nodeVersionsTargetedRequireRange &&
							!versionRange(
								nodeVersionTarget,
								answers.nodeVersionsTargetedRequireRange,
							)
						)
							continue
					} else {
						throw new Error(`invalid target module for the compiler`)
					}
					if (answers.compilerNode === 'babel') {
						const directory =
							`edition-node-${nodeVersionTarget}` +
							(targetModule === 'import' ? '-esm' : '')
						editions.set(
							directory,
							new Edition({
								compiler: 'babel',
								directory,
								index: addExtension(answers.indexEntry, `js`),
								node: addExtension(answers.nodeEntry, `js`),
								browser: addExtension(answers.browserEntry, `js`),
								test: addExtension(answers.testEntry, `js`),
								bin: addExtension(answers.binEntry, `js`),
								tags: ['compiled', 'javascript', targetModule],
								targets: {
									node: nodeVersionTarget,
								},
								engines: {
									node: true,
									browsers: false,
								},
							}),
						)
					} else if (answers.compilerNode === 'typescript') {
						// fetch the latest es version for the node.js version target that typescript supports
						const esVersionTarget = intersect(
							allTypescriptTargets,
							await fetchAllCompatibleESVersionsForNodeVersions([
								nodeVersionTarget,
							]),
						)[0]
						// check that typescript supported it
						if (!esVersionTarget) continue
						// check that we haven't already generated an edition for this es version target target
						if (esVersionsTargets.has(esVersionTarget)) continue
						esVersionsTargets.add(esVersionTarget)
						// generate the edition
						const esVersionTargetLower = esVersionTarget.toLowerCase()
						const directory =
							`edition-${esVersionTargetLower}` +
							(targetModule === 'import' ? '-esm' : '')
						editions.set(
							directory,
							new Edition({
								compiler: 'typescript',
								directory,
								index: addExtension(answers.indexEntry, `js`),
								node: addExtension(answers.nodeEntry, `js`),
								browser: addExtension(answers.browserEntry, `js`),
								test: addExtension(answers.testEntry, `js`),
								bin: addExtension(answers.binEntry, `js`),
								tags: [
									'compiled',
									'javascript',
									esVersionTargetLower,
									targetModule,
								],
								targets: {
									node: nodeVersionTarget,
									es: esVersionTarget,
								},
								engines: {
									node: true,
									browsers: false,
								},
							}),
						)
					} else {
						throw new Error(`invalid target for the compiler`)
					}
				}
			}
		}

update old history formats

## History

- v2.0.2 March 7, 2013
	- Repackaged
	- Dependency upgrades
		-  `hogan.js` from 2.0.x to ~2.0.0
		-  `coffee-script` from 1.3.x to ~1.4.0

- v2.0.1 August 10, 2012
	- Re-added markdown files to npm distribution as they are required for the npm website

- v2.0.0 Unknown
	- Updated for DocPad v6

- v1.0.0 April 14, 2012
	- Updated for DocPad v5.0

  • change heading from ## to #
  • change dates from Month Day, Year to Year Month Day

Consider shrinking editions that only add compat to unsupported versions

Currently in my upcoming version I've added a shrinkNodeTests which will shrink tests if an unsupported (but still tested) version fails.

However, native-promise-pool supports node v10 due to a single edition:

determining engines for edition [edition-es2022-esm]...
target:      *
passed:      12.22.12, 14.21.3, 16.20.2, 18.18.2, 20.9.0, 21.1.0
.unique:     12.22.12, 14.21.3, 16.20.2, 18.18.2, 20.9.0, 21.1.0
failed:      
.unique:     
range:       12 || 14 || 16 || 18 || 20 || 21
...determined engines for edition [edition-es2022-esm] as [12 || 14 || 16 || 18 || 20 || 21] against [12.22.12, 14.21.3, 16.20.2, 18.18.2, 20.9.0, 21.1.0]
determining engines for edition [edition-es2022]...
target:      *
passed:      12.22.12, 14.21.3, 16.20.2, 18.18.2, 20.9.0, 21.1.0
.unique:     12.22.12, 14.21.3, 16.20.2, 18.18.2, 20.9.0, 21.1.0
failed:      10.24.1
.unique:     10.24.1
range:       12 || 14 || 16 || 18 || 20 || 21
...determined engines for edition [edition-es2022] as [12 || 14 || 16 || 18 || 20 || 21] against [10.24.1, 12.22.12, 14.21.3, 16.20.2, 18.18.2, 20.9.0, 21.1.0]
determining engines for edition [edition-es2021]...
target:      *
passed:      10.24.1, 12.22.12, 14.21.3, 16.20.2, 18.18.2, 20.9.0, 21.1.0
.unique:     10.24.1
failed:      
.unique:     
range:       10 || 12 || 14 || 16 || 18 || 20 || 21
...determined engines for edition [edition-es2021] as [10 || 12 || 14 || 16 || 18 || 20 || 21] against [10.24.1, 12.22.12, 14.21.3, 16.20.2, 18.18.2, 20.9.0, 21.1.0]
The project supports the extra versions: 10, 12, 14, 16
The project's Node.js engine has stayed as >=10

Perhaps there should be a shrinkUnsupportedEditions property to trim edition-es2021, so only care about keeping editions that tackle supported node.js versions.

Re-enable macos and windows on ci

Now that dependabot is under control, I can re-enable the macos and windows targets on ci. I should also figure out a way to determine whether they should be optional or required. As things like filedirname and its deps must work on windows.

node.js does not support "module" entry, instead it requires a convoluted solution

index.cjs

'use strict'

/** @type {typeof import("./source/index.ts") } */
module.exports = require('editions').requirePackage(__dirname, require)

index.mjs

export * from './edition-browsers/index.mjs'

package.json

{
  "main": "index"
}

with all files within the edition being changes to mjs or cjs

using package.json:type enforces the type for .js files, so if you do both in a package, it all goes to poop

an alternative approach may be to write a package.json file in each edition, such as ./edition-browsers/package.json:

{
  "type": "module"
}

which seems to work

Fix all lingering bevry pty ltd copyrights

Bevry Pty Ltd shutdown on 26/08/2015, with all ip transferred to myself. So boundation should look for active bevry pty ltd copyrights and ensure that they are actually me since 2015

SyntaxError running boundation

❯ npx boundation
npx: installed 176 in 26.093s
(node:8740) ExperimentalWarning: The ESM module loader is experimental.
file:///C:/Users/xxx/node_modules/boundation/node_modules/githubauthreq/edition-node-esm/index.js:6
export function validate(credentials = process?.env) {
                                               ^

SyntaxError: Unexpected token '.'

node: v12.8.2, v12.18.3

Add `types` field to exports to resolve `node16` and `nodenext` typescript module resolution

Several of the Bevry projects have users trying to use this new module resolution in TypeScript >= 4.7. Bevry hasn't encountered this yet as we just use node as the module resolution.

The solution to this is to have boundation generate a types export, this will resolve it on all Bevry projects and prevent reversion of manual changes from these PRs:

And these issues:

curl flags

for reference, these are the curl flags that are used

-S, --show-error
When used with -s, --silent, it makes curl show an error message  if  it
fails.

-s, --silent
Silent  or  quiet  mode.  Don't  show  progress meter or error messages.
Makes Curl mute. It will still output the data you ask for,  potentially
even to the terminal/stdout unless you redirect it.

Use  -S,  --show-error  in  addition  to this option to disable progress
meter but still show error messages.

See also -v, --verbose and --stderr.

-f, --fail
(HTTP) Fail silently (no output at all) on server errors. This is mostly
done  to  better enable scripts etc to better deal with failed attempts.
In normal cases when an HTTP server fails  to  deliver  a  document,  it
returns  an HTML document stating so (which often also describes why and
more). This flag will prevent curl from outputting that and return error
22.

This  method is not fail-safe and there are occasions where non-success-
ful response codes will slip through, especially when authentication  is
involved (response codes 401 and 407).

-L, --location
(HTTP) If the server reports that the requested page has moved to a dif-
ferent  location  (indicated  with a Location: header and a 3XX response
code), this option will make curl redo the request on the new place.  If
used  together  with  -i,  --include  or  -I,  --head,  headers from all
requested pages will be shown. When authentication is  used,  curl  only
sends its credentials to the initial host. If a redirect takes curl to a
different host, it won't be able to  intercept  the  user+password.  See
also  --location-trusted on how to change this. You can limit the amount
of redirects to follow by using the --max-redirs option.

When curl follows a redirect and the request is not  a  plain  GET  (for
example POST or PUT), it will do the following request with a GET if the
HTTP response was 301, 302, or 303. If the response code was  any  other
3xx code, curl will re-send the following request using the same unmodi-
fied method.

You can tell curl to not change the non-GET request method to GET  after
a  30x  response  by  using  the  dedicated options for that: --post301,
--post302 and --post303.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.