milesj / boost Goto Github PK

Provide a layer that maps both to each other.

yarn run v1.9.4
$ beemo jest
Please select a command!

this.out is not a function
at Console.clearLinesOutput (/Users/miles_johnson/Sites/airlab/repos/dev-cli/node_modules/@boost/core/lib/Console.js:116:14)
at Console.handleRender (/Users/miles_johnson/Sites/airlab/repos/dev-cli/node_modules/@boost/core/lib/Console.js:69:18)
at Timeout.refreshTimer.setTimeout (/Users/miles_johnson/Sites/airlab/repos/dev-cli/node_modules/@boost/core/lib/Console.js:281:18)
at ontimeout (timers.js:475:11)
at tryOnTimeout (timers.js:310:5)
at Timer.listOnTimeout (timers.js:270:5)

I initially wrote Contract to freeze options as a means for consumers to not bypass validation. However, it doesn't seem like mutating the options throws an error, it's just a no-op, which is confusing.

https://github.com/milesj/boost/blob/master/packages/common/src/Contract.ts#L20

Would be useful to be able to load a typescript module and have it downlevel to esm, and import with a dynamic import instead. Not sure how complicated this would be to get working.

Use case is working with esm only libraries from a ts file/script.

Node allows using dynamic imports from CommonJS modules, but compiling ts with dynamic imports will replace those imports with require instead.

Allows consumers to hook into validation and defaults.

Not at the pool level.

These methods simply pipe to the console instance, so move these methods to the console and require consumers to use that instead.

That being said, these names are rather confusing, as they aren't really "logging" in the classic sense. They simply set output to show on the success or failure of the console render loop. Perhaps rename to outOnSuccess or outOnFailure?

Secondly, logLive just wraps console.log, so just have consumers use that approach.

Because why not.

Right now our instance checks us instanceof and constructor name comparison as a fallback. This is obviously very brittle, so let's move to symbols and Symbol.hasInstance checks. This wouldn't be a breaking change if it weren't for Tool#registerPlugin, which will now require a unique symbol to be passed.

So that consumers can check if a plugin is enabled instead of tool.config.drivers.includes('typescript'), which doesnt support the object/instance notation.

Reference repo: https://github.com/natesulat/SampleRepo

Working on a project at work where I'm using @boost/translate to generate a static map of translations. The locale is passed to the NodeJS script using a Shell argument.

Locally, it works as expected, but when using Github Actions, the behavior changes.

Implementation
JS: https://github.com/natesulat/SampleRepo/blob/master/Demo.js
Shell: https://github.com/natesulat/SampleRepo/blob/master/show-the-issue.sh
Translation files: https://github.com/natesulat/SampleRepo/tree/master/language

Expected
This is what happens locally

sh ./show-the-issue.sh en-US
Locale is en-US
{"KEY":"favor","ONLY_EN":"hello","ONLY_US":"howdy","OVERRIDE":"LEET"}
sh ./show-the-issue.sh
Locale is en
{"KEY":"favour","ONLY_EN":"hello","ONLY_US":"onlyUS","OVERRIDE":"LEET"}
sh ./show-the-issue.sh dev
Locale is dev
{"KEY":"F4V0|2","ONLY_EN":"onlyEN","ONLY_US":"onlyUS","OVERRIDE":"1337"}

Actual
In Github Actions, there is no difference in output if the locale input is en-US or en
https://github.com/natesulat/SampleRepo/runs/669497498?check_suite_focus=true#step:5:1

Not sure if this is an issue with i18next or not, but this is the library we're using as a dependency in our project, so figured I'd come here first to ask for help.

Let me know if I can provide anymore info!

The i18n instance is so large it breaks console logs and test diffs.

• ToolPluginRegistry -> PluginRegistry

Look into proper Windows support. Figure out what doesn't work correctly.

Similar to TypeScripts: https://github.com/Microsoft/TypeScript/blob/fadd95f72b5ad7f7f1cffa2b6ac82f612694462c/src/compiler/diagnosticMessages.json

Easier to debug.

Place ENV at bottom, and show buffered output.

They're a bit confusing. Perhaps appName -> bin and appPath -> root. If we rename it to root, we should rename the old root to cwd.

Since we're not showing output, disable the loop. We also shouldn't buffer streams in this case either.

Both of these Tool options require the consumer to explicitly install optimal. Let's try and remove this dependency, perhaps following blueprint(), and passing the predicates through a function.

new Tool({
  configBlueprint({ string }) {
    return { foo: string() };
  },
});

With an API that works similar to the debugger.

const log = this.tool.createLogger();

log();
log.error();
log.warning();
log.critical();
log.info();

Logs can either be written to a log file or piped to the console output.

Since instanceof is problematic.

A lot of Boost functionality can be isolated into reusable packages:

• @boost/args - Argument parsing.
• @boost/cli - Command line application.
• @boost/common - Common utils.
  • Move helpers from core.
• @boost/config - Config loading process.
• @boost/console - Console rendering loop + reporters. (Will use ink in the CLI instead).
• @boost/core - Tool instance that inherits everything. Similar to v1. (No longer necessary after the split).
• @boost/debug - Debugging.
• @boost/event - Event emitter.
• @boost/log - Logging.
• @boost/pipeline - Routines and tasks.
• @boost/plugin - Module and plugin architecture.
• @boost/translate - Translations and i18n.

Ideally @boost/core just pieces these all together but they should be usable stand alone.

However, the biggest blocker is that many classes require a Tool instance in the constructor, but the Tool is composed of all these modules. We would need a new "Tool like" instance that is passed to these modules that provide the shared logic, mainly options, config, translations, debugging, etc.

Hey! Just found this package after looking for something more up-to-date than typescript-memoize and so far it looks great! However, I'm having some difficulty building it into my project.

When trying to import the Memoize method into my Typescript project, as outlined in the docs, I'm getting the warning below with Webpack:

ERROR in ./node_modules/.pnpm/@[email protected]/node_modules/@boost/decorators/esm/index.js 243:0
Module parse failed: 'import' and 'export' may appear only with 'sourceType: module' (243:0)
You may need an appropriate loader to handle this file type, currently no loaders are configured to process this file. See https://webpack.js.org/concepts#loaders
| }
|
> export { Bind, Debounce, Deprecate, Memoize, Throttle };
| //# sourceMappingURL=index.js.map
|
 @ ./application/index.ts 3:0-16

webpack 5.87.0 compiled with 1 error in 7774 ms

I noticed that when I changed the type key to module in the @boost/decorators package.json file, it imported successfully! However, I recognise that it isn't sustainable, and from what I can determine on the migrations to 4.0 page, is a deliberate decision.

Is there something I'm missing? I feel like there's an obvious oversight of mine here, but I'm not sure what to do to make it play nicely.

Details of my config and versions below.
Thanks!

Webpack config (trimmed for confidentiality/brevity):

import path, { sep } from "node:path";
import PathsPlugin from "tsconfig-paths-webpack-plugin";
import ForkTypescriptCheckPlugin from "fork-ts-checker-webpack-plugin";
import HtmlWebpackPlugin from "html-webpack-plugin";
import { Configuration, Module } from "webpack";

const WebpackConfig: Configuration = {
	mode: "development",
	devtool: "eval-source-map",
	plugins: [new ForkTypescriptCheckPlugin()]
	entry: { [...] },
	output: {
		path: path.resolve(__dirname, "dist"),
		filename: "[name].[contenthash].js",
		clean: true,
		publicPath: public_path
	},
	module: {
		rules: [
			{
				test: /\.ts$/,
				use: [{ loader: "ts-loader", options: { transpileOnly: true } }],
				exclude: /[\\/]node_modules[\\/]/
			},
			{ test: /\.css$/i, type: "asset/source" },
			{ test: /\.(png|jpe?g|gif)$/i, type: "asset/resource" },
			{ test: /\.(html|svg)$/i, loader: "html-loader" },
			{ resourceQuery: /raw/, type: "asset/source" }
		]
	},
	resolve: {
		plugins: [new PathsPlugin({ configFile: "./tsconfig.json" })],
		extensions: [".ts", ".js"]
	},
	plugins: [
		new HtmlWebpackPlugin([...])
	],
	optimization: {
		splitChunks: {
			chunks: "all",
			cacheGroups: {
				vendor: {
					test: new RegExp(`${sep}node_modules${sep}`, "i"),
					name: (module: Module, chunks: any, cacheGroupKey: string) => { [...] },					},
					reuseExistingChunk: true,
					maxSize: 1 * 1000 * 1000 // 1mb
				},
				app: {
					test: new RegExp(`${sep}application${sep}(?!entry\.ts)`, "i"),
					name: (module: any) => { [...] },
					chunks: "all",
					maxSize: 500 * 1000 // 500kb
				}
			}
		}
	}
};

export default WebpackConfig;

My webpack and typescript versions are:

Webpack:
  System:
    OS: Linux 5.15 Arch Linux
    CPU: (12) x64 12th Gen Intel(R) Core(TM) i7-1265U
    Memory: 4.51 GB / 7.76 GB
  Binaries:
    Node: 20.2.0 - ~/.local/share/pnpm/node
    Yarn: 1.22.19 - /usr/sbin/yarn
    npm: 9.6.6 - ~/.local/share/pnpm/npm
  Packages:
    compression-webpack-plugin: ^10.0.0 => 10.0.0 
    css-loader: ^6.8.1 => 6.8.1 
    file-loader: ^6.2.0 => 6.2.0 
    fork-ts-checker-webpack-plugin: ^8.0.0 => 8.0.0 
    html-loader: ^4.2.0 => 4.2.0 
    html-webpack-plugin: ^5.5.3 => 5.5.3 
    raw-loader: ^4.0.2 => 4.0.2 
    style-loader: ^3.3.3 => 3.3.3 
    ts-loader: ^9.4.3 => 9.4.3 
    tsconfig-paths-webpack-plugin: ^4.0.1 => 4.0.1 
    webpack: ^5.87.0 => 5.87.0 
    webpack-cli: ^5.1.4 => 5.1.4  

Typescript: Version 4.9.3

A bit out of order right now.

This is a great list of guidelines. Make sure we're following them: https://clig.dev/

Just standardize so all impls are the same.

Some features have a large startup cost (like i18n), so lazy-load whenever possible. Other features that may benefit from this is the debugger, console, and loaders.

Instead of having the theme property names be based on routine statuses, they should be based on states like warning, danger, success, etc.