Skeleton: An easy way to create sliding CAGradientLayer animations!

Skeleton

Skeleton is an easy way to create sliding CAGradientLayer animations! It works great for creating skeleton screens:

👩‍💻 Usage

The entire library comes down to just one public-facing extension:

public extension CAGradientLayer {
  public func slide(to dir: Direction, group: ((CAAnimationGroup) -> Void) = { _ in })
  public func stopSliding()
}

You can check out the example and the documentation for more.

📚 Example

To run the example project, clone the repo, and run pod install from the Example directory first.

🛠 Installation

Skeleton is available through CocoaPods. To install it, simply add the following line to your Podfile:

pod "Skeleton"

Skeleton is also available through Carthage. Add this to your Cartfile:

github "gonzalonunez/Skeleton" ~> 0.4.0

Download Details:

Author: Gonzalonunez
Source Code: https://github.com/gonzalonunez/Skeleton 
License: MIT license

#swift #ios #skeleton #loader #gradient 

Pro Calendar: A Best Professional Calendar Ever for Vue.js

Pro Calendar

Another one Best Professional Calendar ever

Install

npm i @lbgm/pro-calendar-vue

Screenshot

Use

main.ts

import { ProCalendar } from "@lbgm/pro-calendar-vue";

//...

app.use(ProCalendar);

App.vue

<script setup lang="ts">
import "@lbgm/pro-calendar-vue/style";

</script>

<template>
<!-- all props are optional -->
<pro-calendar
  :events="evts"
  :loading="false"
  :config="cfg"
  view="week"
  date="'isoStringDate'"
  @calendarClosed="void 0"
  @fetchEvents="void 0"
/>
</template>

Props

// interface
interface Props {
  date?: string | null;
  view?: string;
  events?: Appointment[];
  loading?: boolean;
  config?: {
    actions?: {
      view?: {
        enabled?: boolean;
        icon?: boolean;
        text?: string;
      };
      report?: {
        enabled?: boolean;
        icon?: boolean;
        text?: string;
      };
    };
    searchPlaceHolder?: string;
    eventName?: string;
    closeText?: string;
  };
}

// defaults
{
  date: null,
  view: "",
  events: () => [],
  loading: false,
  config: () => ({
    actions: {
      view: {
        enabled: true,
        icon: true,
        text: "",
      },
      report: {
        enabled: true,
        icon: true,
        text: "",
      },
    },
    searchPlaceHolder: "",
    eventName: "",
    closeText: "",
  }),
}

Prop events type

interface Appointment {
  date: string, //DateIsoString
  comment?: string,
  createdAt?: string, //DateIsoString
  id: string,
  updatedAt?: string, //DateIsoString
  keywords: string,
  name: string,
}

events: Appointment[];

Prop view type

'day' | 'week' | 'month'

Events

@calendarClosed: This event is fired when user clicks close button.

@fetchEvents: This event is fired when date selected changes. $event: { start: string; end: string }. start and end are iso string date.

Slots

Draw your own calendars using scoped slots

<pro-calendar
  :events="evts"
  :loading="false"
  :config="cfg"
  view="week"
  date="'isoStringDate'"
>
  <template #leftSwitchArrow>
    <!-- replace left switch arrow with this slot -->
  </template>

  <template #rightSwitchArrow>
    <!-- replace left switch arrow with this slot -->
  </template>

  <template #closeButton>
    <!-- replace close button with this slot -->
  </template>

  <template #loader="{ calendarGotLoading }">
    <!-- replace calendar loader with this slot -->
  </template>

  <template #searchIcon>
    <!-- replace search widget icon with this slot -->
  </template>

  <template #dateLeftArrow>
    <!-- replace date picker left arrow with this -->
  </template>

  <template #dateRightArrow>
    <!-- replace date picker right arrow with this -->
  </template>

  <template #sideEvent="{ dateSelected, calendarEvents }">
    <!-- use this slot to show yourself side events in appearance you want -->
    <!--
      dateSelected: Date;
      calendarEvents: Appointment[]; // all events
    -->
  </template>

  <template #eventCard="{ date, time, cardEvent }">
    <!-- use this slot to show yourself calendar event in appearance you want -->
    <!--
      date: Date;
      time: string;
      cardEvent: Appointment[]; // events according to date/time
    -->
  </template>
</pro-calendar>

Custom Events fired

calendar.request.view & calendar.request.report

When the user clicks on view or report action, an custom html event is fired with the id of event in detail. You can listen these events like this:

<script setup lang="ts">
import { ref, onMounted } from "vue";

onMounted(() => {
  ["calendar.request.view", "calendar.request.report"].forEach((e: string) => {
    document.body.addEventListener(e, (event: Event | CustomEvent) => {
      console.log({ event });
    });
  });
});

</script>

Download details:

Author: lbgm
Source code: https://github.com/lbgm/pro-calendar-vue

#vue 

TS-loader: TypeScript Loader for Webpack

TypeScript loader for webpack

ts-loader

This is the TypeScript loader for webpack.

Getting Started

Installation

yarn add ts-loader --dev

or

npm install ts-loader --save-dev

You will also need to install TypeScript if you have not already.

yarn add typescript --dev

or

npm install typescript --save-dev

Running

Use webpack like normal, including webpack --watch and webpack-dev-server, or through another build system using the Node.js API.

Examples

We have a number of example setups to accommodate different workflows. Our examples can be found here.

We probably have more examples than we need. That said, here's a good way to get started:

• I want the simplest setup going. Use "vanilla" ts-loader
• I want the fastest compilation that's available. Use fork-ts-checker-webpack-plugin. It performs type checking in a separate process with ts-loader just handling transpilation.

Faster Builds

As your project becomes bigger, compilation time increases linearly. It's because typescript's semantic checker has to inspect all files on every rebuild. The simple solution is to disable it by using the transpileOnly: true option, but doing so leaves you without type checking and will not output declaration files.

You probably don't want to give up type checking; that's rather the point of TypeScript. So what you can do is use the fork-ts-checker-webpack-plugin. It runs the type checker on a separate process, so your build remains fast thanks to transpileOnly: true but you still have the type checking.

If you'd like to see a simple setup take a look at our example.

Yarn Plug’n’Play

ts-loader supports Yarn Plug’n’Play. The recommended way to integrate is using the pnp-webpack-plugin.

Babel

ts-loader works very well in combination with babel and babel-loader. There is an example of this in the official TypeScript Samples.

Compatibility

• TypeScript: 3.6.3+
• webpack: 5.x+ (please use ts-loader 8.x if you need webpack 4 support)
• node: 12.x+

A full test suite runs each night (and on each pull request). It runs both on Linux and Windows, testing ts-loader against major releases of TypeScript. The test suite also runs against TypeScript@next (because we want to use it as much as you do).

If you become aware of issues not caught by the test suite then please let us know. Better yet, write a test and submit it in a PR!

Configuration

Create or update webpack.config.js like so:

module.exports = {
  mode: "development",
  devtool: "inline-source-map",
  entry: "./app.ts",
  output: {
    filename: "bundle.js"
  },
  resolve: {
    // Add `.ts` and `.tsx` as a resolvable extension.
    extensions: [".ts", ".tsx", ".js"],
    // Add support for TypeScripts fully qualified ESM imports.
    extensionAlias: {
     ".js": [".js", ".ts"],
     ".cjs": [".cjs", ".cts"],
     ".mjs": [".mjs", ".mts"]
    }
  },
  module: {
    rules: [
      // all files with a `.ts`, `.cts`, `.mts` or `.tsx` extension will be handled by `ts-loader`
      { test: /\.([cm]?ts|tsx)$/, loader: "ts-loader" }
    ]
  }
};

Add a tsconfig.json file. (The one below is super simple; but you can tweak this to your hearts desire)

{
  "compilerOptions": {
    "sourceMap": true
  }
}

The tsconfig.json file controls TypeScript-related options so that your IDE, the tsc command, and this loader all share the same options.

devtool / sourcemaps

If you want to be able to debug your original source then you can thanks to the magic of sourcemaps. There are 2 steps to getting this set up with ts-loader and webpack.

First, for ts-loader to produce sourcemaps, you will need to set the tsconfig.json option as "sourceMap": true.

Second, you need to set the devtool option in your webpack.config.js to support the type of sourcemaps you want. To make your choice have a read of the devtool webpack docs. You may be somewhat daunted by the choice available. You may also want to vary the sourcemap strategy depending on your build environment. Here are some example strategies for different environments:

• devtool: 'inline-source-map' - Solid sourcemap support; the best "all-rounder". Works well with karma-webpack (not all strategies do)
• devtool: 'eval-cheap-module-source-map' - Best support for sourcemaps whilst debugging.
• devtool: 'source-map' - Approach that plays well with UglifyJsPlugin; typically you might use this in Production

Code Splitting and Loading Other Resources

Loading css and other resources is possible but you will need to make sure that you have defined the require function in a declaration file.

declare var require: {
  <T>(path: string): T;
  (paths: string[], callback: (...modules: any[]) => void): void;
  ensure: (
    paths: string[],
    callback: (require: <T>(path: string) => T) => void
  ) => void;
};

Then you can simply require assets or chunks per the webpack documentation.

require("!style!css!./style.css");

The same basic process is required for code splitting. In this case, you import modules you need but you don't directly use them. Instead you require them at split points. See this example and this example for more details.

TypeScript 2.4 provides support for ECMAScript's new import() calls. These calls import a module and return a promise to that module. This is also supported in webpack - details on usage can be found here. Happy code splitting!

Declaration Files (.d.ts)

To output declaration files (.d.ts), you can set "declaration": true in your tsconfig and set "transpileOnly" to false.

If you use ts-loader with "transpileOnly": true along with fork-ts-checker-webpack-plugin, you will need to configure fork-ts-checker-webpack-plugin to output definition files, you can learn more on the plugin's documentation page: https://github.com/TypeStrong/fork-ts-checker-webpack-plugin#typescript-options

To output a built .d.ts file, you can use the DeclarationBundlerPlugin in your webpack config.

Failing the build on TypeScript compilation error

The build should fail on TypeScript compilation errors as of webpack 2. If for some reason it does not, you can use the webpack-fail-plugin.

For more background have a read of this issue.

baseUrl / paths module resolution

If you want to resolve modules according to baseUrl and paths in your tsconfig.json then you can use the tsconfig-paths-webpack-plugin package. For details about this functionality, see the module resolution documentation.

This feature requires webpack 2.1+ and TypeScript 2.0+. Use the config below or check the package for more information on usage.

const TsconfigPathsPlugin = require('tsconfig-paths-webpack-plugin');

module.exports = {
  ...
  resolve: {
    plugins: [new TsconfigPathsPlugin({ configFile: "./path/to/tsconfig.json" })]
  }
  ...
}

Options

There are two types of options: TypeScript options (aka "compiler options") and loader options. TypeScript options should be set using a tsconfig.json file. Loader options can be specified through the options property in the webpack configuration:

module.exports = {
  ...
  module: {
    rules: [
      {
        test: /\.tsx?$/,
        use: [
          {
            loader: 'ts-loader',
            options: {
              transpileOnly: true
            }
          }
        ]
      }
    ]
  }
}

Loader Options

transpileOnly

If you want to speed up compilation significantly you can set this flag. However, many of the benefits you get from static type checking between different dependencies in your application will be lost. transpileOnly will not speed up compilation of project references.

It's advisable to use transpileOnly alongside the fork-ts-checker-webpack-plugin to get full type checking again. To see what this looks like in practice then either take a look at our example.

Tip: When you add the fork-ts-checker-webpack-plugin to your webpack config, the transpileOnly will default to true, so you can skip that option.

If you enable this option, webpack 4 will give you "export not found" warnings any time you re-export a type:

WARNING in ./src/bar.ts
1:0-34 "export 'IFoo' was not found in './foo'
 @ ./src/bar.ts
 @ ./src/index.ts

The reason this happens is that when typescript doesn't do a full type check, it does not have enough information to determine whether an imported name is a type or not, so when the name is then exported, typescript has no choice but to emit the export. Fortunately, the extraneous export should not be harmful, so you can just suppress these warnings:

module.exports = {
  ...
  stats: {
    warningsFilter: /export .* was not found in/
  }
}

happyPackMode

If you're using HappyPack or thread-loader to parallelise your builds then you'll need to set this to true. This implicitly sets *transpileOnly* to true and WARNING! stops registering all errors to webpack.

It's advisable to use this with the fork-ts-checker-webpack-plugin to get full type checking again. IMPORTANT: If you are using fork-ts-checker-webpack-plugin alongside HappyPack or thread-loader then ensure you set the syntactic diagnostic option like so:

        new ForkTsCheckerWebpackPlugin({
          typescript: {
            diagnosticOptions: {
              semantic: true,
              syntactic: true,
            },
          },
        })

This will ensure that the plugin checks for both syntactic errors (eg const array = [{} {}];) and semantic errors (eg const x: number = '1';). By default the plugin only checks for semantic errors (as when used with ts-loader in transpileOnly mode, ts-loader will still report syntactic errors).

Also, if you are using thread-loader in watch mode, remember to set poolTimeout: Infinity so workers don't die.

resolveModuleName and resolveTypeReferenceDirective

These options should be functions which will be used to resolve the import statements and the <reference types="..."> directives instead of the default TypeScript implementation. It's not intended that these will typically be used by a user of ts-loader - they exist to facilitate functionality such as Yarn Plug’n’Play.

getCustomTransformers

Provide custom transformers - only compatible with TypeScript 2.3+ (and 2.4 if using transpileOnly mode). For example usage take a look at typescript-plugin-styled-components or our test.

You can also pass a path string to locate a js module file which exports the function described above, this useful especially in happyPackMode. (Because forked processes cannot serialize functions see more at related issue)

logInfoToStdOut

This is important if you read from stdout or stderr and for proper error handling. The default value ensures that you can read from stdout e.g. via pipes or you use webpack -j to generate json output.

logLevel

Can be info, warn or error which limits the log output to the specified log level. Beware of the fact that errors are written to stderr and everything else is written to stderr (or stdout if logInfoToStdOut is true).

silent

If true, no console.log messages will be emitted. Note that most error messages are emitted via webpack which is not affected by this flag.

ignoreDiagnostics

You can squelch certain TypeScript errors by specifying an array of diagnostic codes to ignore.

reportFiles

Only report errors on files matching these glob patterns.

  // in webpack.config.js
  {
    test: /\.ts$/,
    loader: 'ts-loader',
    options: { reportFiles: ['src/**/*.{ts,tsx}', '!src/skip.ts'] }
  }

This can be useful when certain types definitions have errors that are not fatal to your application.

compiler

Allows use of TypeScript compilers other than the official one. Should be set to the NPM name of the compiler, eg ntypescript.

configFile

Allows you to specify where to find the TypeScript configuration file.

You may provide

• just a file name. The loader then will search for the config file of each entry point in the respective entry point's containing folder. If a config file cannot be found there, it will travel up the parent directory chain and look for the config file in those folders.
• a relative path to the configuration file. It will be resolved relative to the respective .ts entry file.
• an absolute path to the configuration file.

Please note, that if the configuration file is outside of your project directory, you might need to set the context option to avoid TypeScript issues (like TS18003). In this case the configFile should point to the tsconfig.json and context to the project root.

colors

If false, disables built-in colors in logger messages.

errorFormatter

By default ts-loader formats TypeScript compiler output for an error or a warning in the style:

[tsl] ERROR in myFile.ts(3,14)
      TS4711: you did something very wrong

If that format is not to your taste you can supply your own formatter using the errorFormatter option. Below is a template for a custom error formatter. Please note that the colors parameter is an instance of chalk which you can use to color your output. (This instance will respect the colors option.)

function customErrorFormatter(error, colors) {
  const messageColor =
    error.severity === "warning" ? colors.bold.yellow : colors.bold.red;
  return (
    "Does not compute.... " +
    messageColor(Object.keys(error).map(key => `${key}: ${error[key]}`))
  );
}

If the above formatter received an error like this:

{
  "code":2307,
  "severity": "error",
  "content": "Cannot find module 'components/myComponent2'.",
  "file":"/.test/errorFormatter/app.ts",
  "line":2,
  "character":31
}

It would produce an error message that said:

Does not compute.... code: 2307,severity: error,content: Cannot find module 'components/myComponent2'.,file: /.test/errorFormatter/app.ts,line: 2,character: 31

And the bit after "Does not compute.... " would be red.

compilerOptions

Allows overriding TypeScript options. Should be specified in the same format as you would do for the compilerOptions property in tsconfig.json.

instance

Advanced option to force files to go through different instances of the TypeScript compiler. Can be used to force segregation between different parts of your code.

appendTsSuffixTo

appendTsxSuffixTo

A list of regular expressions to be matched against filename. If filename matches one of the regular expressions, a .ts or .tsx suffix will be appended to that filename. If you're using HappyPack or thread-loader with ts-loader, you need use the string type for the regular expressions, not RegExp object.

// change this:
{ appendTsSuffixTo: [/\.vue$/] }
// to:
{ appendTsSuffixTo: ['\\.vue$'] }

This is useful for *.vue file format for now. (Probably will benefit from the new single file format in the future.)

Example:

webpack.config.js:

module.exports = {
  entry: "./index.vue",
  output: { filename: "bundle.js" },
  resolve: {
    extensions: [".ts", ".vue"]
  },
  module: {
    rules: [
      { test: /\.vue$/, loader: "vue-loader" },
      {
        test: /\.ts$/,
        loader: "ts-loader",
        options: { appendTsSuffixTo: [/\.vue$/] }
      }
    ]
  }
};

index.vue

<template><p>hello {{msg}}</p></template>
<script lang="ts">
export default {
  data(): Object {
    return {
      msg: "world"
    };
  }
};
</script>

We can handle .tsx by quite similar way:

webpack.config.js:

module.exports = {
    entry: './index.vue',
    output: { filename: 'bundle.js' },
    resolve: {
        extensions: ['.ts', '.tsx', '.vue', '.vuex']
    },
    module: {
        rules: [
            { test: /\.vue$/, loader: 'vue-loader',
              options: {
                loaders: {
                  ts: 'ts-loader',
                  tsx: 'babel-loader!ts-loader',
                }
              }
            },
            { test: /\.ts$/, loader: 'ts-loader', options: { appendTsSuffixTo: [/TS\.vue$/] } }
            { test: /\.tsx$/, loader: 'babel-loader!ts-loader', options: { appendTsxSuffixTo: [/TSX\.vue$/] } }
        ]
    }
}

tsconfig.json (set jsx option to preserve to let babel handle jsx)

{
  "compilerOptions": {
    "jsx": "preserve"
  }
}

index.vue

<script lang="tsx">
export default {
  functional: true,
  render(h, c) {
    return (<div>Content</div>);
  }
}
</script>

Or if you want to use only tsx, just use the appendTsxSuffixTo option only:

            { test: /\.ts$/, loader: 'ts-loader' }
            { test: /\.tsx$/, loader: 'babel-loader!ts-loader', options: { appendTsxSuffixTo: [/\.vue$/] } }

onlyCompileBundledFiles

The default behavior of ts-loader is to act as a drop-in replacement for the tsc command, so it respects the include, files, and exclude options in your tsconfig.json, loading any files specified by those options. The onlyCompileBundledFiles option modifies this behavior, loading only those files that are actually bundled by webpack, as well as any .d.ts files included by the tsconfig.json settings. .d.ts files are still included because they may be needed for compilation without being explicitly imported, and therefore not picked up by webpack.

useCaseSensitiveFileNames

The default behavior of ts-loader is to act as a drop-in replacement for the tsc command, so it respects the useCaseSensitiveFileNames set internally by typescript. The useCaseSensitiveFileNames option modifies this behavior, by changing the way in which ts-loader resolves file paths to compile. Setting this to true can have some performance benefits due to simplifying the file resolution codepath.

allowTsInNodeModules

By default, ts-loader will not compile .ts files in node_modules. You should not need to recompile .ts files there, but if you really want to, use this option. Note that this option acts as a whitelist - any modules you desire to import must be included in the "files" or "include" block of your project's tsconfig.json.

See: microsoft/TypeScript#12358

  // in webpack.config.js
  {
    test: /\.ts$/,
    loader: 'ts-loader',
    options: { allowTsInNodeModules: true }
  }

And in your tsconfig.json:

  {
    "include": [
      "node_modules/whitelisted_module.ts"
    ],
    "files": [
      "node_modules/my_module/whitelisted_file.ts"
    ]
  }

context

If set, will parse the TypeScript configuration file with given absolute path as base path. Per default the directory of the configuration file is used as base path. Relative paths in the configuration file are resolved with respect to the base path when parsed. Option context allows to set option configFile to a path other than the project root (e.g. a NPM package), while the base path for ts-loader can remain the project root.

Keep in mind that not having a tsconfig.json in your project root can cause different behaviour between ts-loader and tsc. When using editors like VS Code it is advised to add a tsconfig.json file to the root of the project and extend the config file referenced in option configFile. For more information please read the PR that is the base and read the PR that contributed this option.

webpack:

{
  loader: require.resolve('ts-loader'),
  options: {
    context: __dirname,
    configFile: require.resolve('ts-config-react-app')
  }
}

Extending tsconfig.json:

{ "extends": "./node_modules/ts-config-react-app/index" }

Note that changes in the extending file while not be respected by ts-loader. Its purpose is to satisfy the code editor.

experimentalFileCaching

By default whenever the TypeScript compiler needs to check that a file/directory exists or resolve symlinks it makes syscalls. It does not cache the result of these operations and this may result in many syscalls with the same arguments (see comment with example). In some cases it may produce performance degradation.

This flag enables caching for some FS-functions like fileExists, realpath and directoryExists for TypeScript compiler. Note that caches are cleared between compilations.

projectReferences

ts-loader has opt-in support for project references. With this configuration option enabled, ts-loader will incrementally rebuild upstream projects the same way tsc --build does. Otherwise, source files in referenced projects will be treated as if they’re part of the root project.

In order to make use of this option your project needs to be correctly configured to build the project references and then to use them as part of the build. See the Project References Guide and the example code in the examples which can be found here.

Usage with webpack watch

Because TS will generate .js and .d.ts files, you should ignore these files, otherwise watchers may go into an infinite watch loop. For example, when using webpack, you may wish to add this to your webpack.conf.js file:

// for webpack 4
 plugins: [
   new webpack.WatchIgnorePlugin([
     /\.js$/,
     /\.d\.[cm]?ts$/
   ])
 ],

// for webpack 5
plugins: [
  new webpack.WatchIgnorePlugin({
    paths:[
      /\.js$/,
      /\.d\.[cm]ts$/
  ]})
],

It's worth noting that use of the LoaderOptionsPlugin is only supposed to be a stopgap measure. You may want to look at removing it entirely.

Hot Module replacement

We do not support HMR as we did not yet work out a reliable way how to set it up.

If you want to give webpack-dev-server HMR a try, follow the official webpack HMR guide, then tweak a few config options for ts-loader:

1. Set transpileOnly to true (see transpileOnly for config details and recommendations above).
2. Inside your HMR acceptance callback function, maybe re-require the module that was replaced.

Contributing

This is your TypeScript loader! We want you to help make it even better. Please feel free to contribute; see the contributor's guide to get started.

History

ts-loader was started by James Brantly, since 2016 John Reilly has been taking good care of it. If you're interested, you can read more about how that came to pass.

Download Details:

Author: TypeStrong
Source Code: https://github.com/TypeStrong/ts-loader 
License: MIT license

#typescript #webpack #loader 

Simple Library for Loading Translations From Assets Folder

Simple library for loading translations from assets folder. Library should be used with GetX or some similar framework as it just loads files as Map<String, String>.

Two file formats of translation files are supported:

• json
• properties

Features

• simplified internationalization
• supported json and properties files
• all keys from json file are converted as object1.object2.value so that they are the same as in properties file

Getting started

You need to configure assets folder with your translation files. For instance:

flutter:
  uses-material-design: true

  assets:
    - assets/i18n/

Inside that folder you need to put all your translation files. Library does NOT use countryCode of the Locale, just languageCode.

For example:

en.json

{
  "app": {
    "name": "Test application",
    "version": "1",
    "bar": {
      "title": "My title"
    }
  }
}    

hr.properties

app.name=Testna aplikacija
app.version=1
app.bar.title=Moj naslov

And that is it, you just need to configure library inside main application and you'll have all your translations.

NOTE: You need to include flutter_localization in your pubspec:

#....
dependencies:
  flutter:
    sdk: flutter
  flutter_localizations:
    sdk: flutter

  cupertino_icons: ^1.0.3
#....

Usage

To get translations, you just need to use static method loadTranslations inside TranslationsLoader class. For instance: TranslationsLoader.loadTranslations("assets/i18n").

To use this library with GetX library, you need to implement Translations class:

class ApplicationTranslations extends Translations {
  final Map<String, Map<String, String>> _translationKeys;

  ApplicationTranslations(this._translationKeys);

  @override
  Map<String, Map<String, String>> get keys => _translationKeys;
}

Then you can use it when setting your GetMaterialApp:

Future<void> main() async {
  // ...

  runApp(GetMaterialApp(
    translations: ApplicationTranslations(await TranslationsLoader.loadTranslations("assets/i18n")),
    locale: Get.deviceLocale,
    fallbackLocale: defaultLocale,
    supportedLocales: supportedLocales,
    localizationsDelegates: const [
      GlobalMaterialLocalizations.delegate,
      GlobalWidgetsLocalizations.delegate,
      GlobalCupertinoLocalizations.delegate,
    ],
    // .....
  ));
}

Additional information

Use this package as a library

Depend on it

Run this command:

With Flutter:

 $ flutter pub add translations_loader

This will add a line like this to your package's pubspec.yaml (and run an implicit flutter pub get):

dependencies:
  translations_loader: ^1.0.2

Alternatively, your editor might support flutter pub get. Check the docs for your editor to learn more.

Import it

Now in your Dart code, you can use:

import 'package:translations_loader/translations_loader.dart';

example/lib/main.dart

import 'package:flutter/material.dart';
import 'package:flutter_localizations/flutter_localizations.dart';
import 'package:get/get.dart';
import 'package:translations_loader/translations_loader.dart';

const defaultLocale = Locale("en", "US");
const supportedLocales = [
  defaultLocale,
  Locale.fromSubtags(languageCode: "hr")
];

///Class which extends Get Translations
class ApplicationTranslations extends Translations {
  final Map<String, Map<String, String>> _translationKeys;

  ApplicationTranslations(this._translationKeys);

  @override
  Map<String, Map<String, String>> get keys => _translationKeys;
}

/// Main method
Future<void> main() async {
  WidgetsFlutterBinding.ensureInitialized();

  runApp(GetMaterialApp(
      translations: ApplicationTranslations(
          await TranslationsLoader.loadTranslations(
              "assets/i18n")), //can add supported locales param
      locale: Get.deviceLocale,
      fallbackLocale: defaultLocale,
      supportedLocales: supportedLocales,
      localizationsDelegates: const [
        GlobalMaterialLocalizations.delegate,
        GlobalWidgetsLocalizations.delegate,
        GlobalCupertinoLocalizations.delegate,
      ],
      home: const MyHomePage()));
}

///Some default page
class MyHomePage extends StatelessWidget {
  const MyHomePage({Key? key}) : super(key: key);

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        title: Text('app.bar.title'.tr),
      ),
      body: Center(
        child: Column(
          mainAxisAlignment: MainAxisAlignment.center,
          children: <Widget>[
            Text(
              'page.home.current_lang'.tr +
                  ': ' +
                  'lang.${Get.locale?.languageCode}'.tr,
            ),
            Card(
              child: Row(
                crossAxisAlignment: CrossAxisAlignment.center,
                mainAxisAlignment: MainAxisAlignment.center,
                children: [
                  MaterialButton(
                      child: Text('lang.en'.tr),
                      onPressed: () => {Get.updateLocale(supportedLocales[0])}),
                  MaterialButton(
                      child: Text('lang.hr'.tr),
                      onPressed: () => {Get.updateLocale(supportedLocales[1])})
                ],
              ),
            )
          ],
        ),
      ),
    );
  }
}

Download Details:

Author: anCRONIK
Source Code: https://github.com/anCRONIK/translations_loader 
License: MIT license

#flutter #dart #loader 

Shinycustomloader: Add A Custom Loader for R Shiny

shinycustomloader 

Overview

This R-package is an extension to the shinycssloaders package and allows for custom css/html or gif/image file for the loading screen. You may include your css/html files or gif/image files for your custom loading screen. There are twelve built in css/html loading screen specified by dnaspin, pacman, loader1, loader2, ..., loader10.

You can install this package from github as:

Installation

# You can install it from CRAN:
install.packages("shinycustomloader")

# Or the the development version from GitHub:
# install.packages("devtools")
devtools::install_github('emitanaka/shinycustomloader')

Example

You can see an example shiny app that employs the custom loaders by launching an example app in the package.

library(shinycustomloader)
shinyExample()

Customisation

The command is a simple wrapper for the shiny output and you can easily specify your own favorite gif (say nyancat.gif) for customisation. Place nyancat.gif in the folder www within your shiny app folder (create one if you don't have it in your shiny folder).

withLoader(plotOutput("distPlot"), type="image", loader="nyancat.gif")

You can also further customise by inputting your own text as a marquee object with its own style.

Download Details:

Author: Emitanaka
Source Code: https://github.com/emitanaka/shinycustomloader 

#r #rstats #loader 

Add Loading animations to A Shiny Output While It's Recalculating

{shinycssloaders} - Add loading animations to a Shiny output while it's recalculating 

When a Shiny output (such as a plot, table, map, etc.) is recalculating, it remains visible but gets greyed out. Using {shinycssloaders}, you can add a loading animation ("spinner") to outputs instead of greying them out. By wrapping a Shiny output in withSpinner(), a spinner will automatically appear while the output is recalculating.

You can choose from one of 8 built-in animation types, and customize the colour/size. You can also use your own image instead of the built-in animations. See the demo Shiny app online for examples.

Example

For interactive examples and to see some of the features, check out the demo app.

Below is a simple example of what {shinycssloaders} looks like:

How to use

Simply wrap a Shiny output in a call to withSpinner(). If you have %>% loaded, you can use it, for example plotOutput("myplot") %>% withSpinner().

Basic usage:

library(shiny)

ui <- fluidPage(
    actionButton("go", "Go"),
    shinycssloaders::withSpinner(
        plotOutput("plot")
    )
)
server <- function(input, output) {
    output$plot <- renderPlot({
        input$go
        Sys.sleep(1.5)
        plot(runif(10))
    })
}
shinyApp(ui, server)

Installation

To install the stable CRAN version:

install.packages("shinycssloaders")

To install the latest development version from GitHub:

install.packages("remotes")
remotes::install_github("daattali/shinycssloaders")

Features

8 customizable built-in spinners

You can use the type parameter to choose one of the 8 built-in animations, the color parameter to change the spinner's colour, and size to make the spinner smaller or larger (2 will make the spinner twice as large). For example, withSpinner(plotOutput("myplot"), type = 5, color = "#0dc5c1", size = 2).

Setting spinner parameters globally

If you want all the spinners in your app to have a certain type/size/colour, instead of specifying them in each call to withSpinner(), you can set them globally using the spinner.type, spinner.color, spinner.size R options. For example, setting options(spinner.color="#0dc5c1") will cause all your spinners to use that colour.

Using a custom image

If you don't want to use any of the built-in spinners, you can also provide your own image (either a still image or a GIF) to use instead, using the image parameter.

Specifying the spinner height

The spinner attempts to automatically figure out the height of the output it replaces, and to vertically center itself. For some outputs (such as tables), the height is unknown, so the spinner will assume the output is 400px tall. If your output is expected to be significantly smaller or larger, you can use the proxy.height parameter to adjust this.

Showing a spinner on top of the output

By default, the out-dated output gets hidden while the spinner is showing. You can change this behaviour to have the spinner appear on top of the old output using the hide.ui = FALSE parameter.

Background colour

Spinner types 2 and 3 require you to specify a background colour. It's recommended to use a colour that matches the background colour of the output's container, so that the spinner will "blend in".

Sponsors 🏆

There are no sponsors yet

Become the first sponsor for {shinycssloaders}!

Credits

The 8 built-in animations are taken from https://projects.lukehaas.me/css-loaders/.

The package was originally created by Andrew Sali.

Download Details:

Author: Daattali
Source Code: https://github.com/daattali/shinycssloaders 
License: View license

#r #loader #rstats 

istanbul-loader: A Code Coverage-instrumenting Webpack Loader

istanbul-loader

This is a webpack loader that uses istanbul-lib-instrument to add code coverage instrumentation to JavaScript files.

Installation

Install with

npm install @theintern/istanbul-loader --save-dev

Usage

Install the loader in a project and add an entry for it to the project's webpack.config:

module: {
    rules: [
        {
            test: /src\/.*\.ts$/,
            use: '@theintern/istanbul-loader'
        },
        ...
    ]
}

Note that the istanbul-loader should be run after transpilers such as TypeScript. This means that it should come before transpilers in a loader list, or use enforce: 'post':

rules: [
    {
        test: /src\/.(\.ts$/,
        use: [ '@theintern/istanbul-loader', 'ts-node' ]
    },
    ...
]

or

rules: [
    {
        test: /src\/.(\.ts$/,
        use: '@theintern/istanbul-loader',
        enforce: 'post'
    },
    ...
]

Configuration

The rule test should only match source files, not all .ts or .js files, so as not to instrument tests or support files.

Options can be passed using the standard webpack options property:

rules: [
    {
        test: /src\/.(\.ts$/,
        use: {
            loader: '@theintern/istanbul-loader',
            options: { config: 'tests/intern.json' }
        }
    },
    ...
]

Currently the only option used by the loader is 'config', which should point to an Intern config file. The loader will use values for coverageVariable and instrumenterOptions from the Intern config, if present.

Download Details: 

Author: Theintern
Source Code: https://github.com/theintern/istanbul-loader 
License: View license

#typescript #loader #webpack 

Dojo/loader: Dojo 2 - AMD Loader

@dojo/loader

This package provides a JavaScript AMD loader useful in applications running in either a web browser, node.js or nashorn.

@dojo/loader does not have any dependencies on a JavaScript framework.

Note

We strongly recommend using the @dojo/cli build tools for a Dojo 2 application over a runtime loader such as @dojo/loader.

Usage

To use @dojo/loader, install the package:

npm install @dojo/loader

Support

Features

• AMD loading
• CJS loading (in a node environment)
• Plugins:
  • text
  • has
• Loading in a Nashorn environment

Use a script tag to import the loader. This will make require and define available in the global namespace.

<script src='node_modules/@dojo/loader/loader.min.js'></script>

The loader can load both AMD and CJS formatted modules.

There is no need to use the Dojo 1.x method of requiring node modules via dojo/node! plugin anymore.

How do I contribute?

We appreciate your interest! Please see the Guidelines Repository for the Contributing Guidelines.

Code Style

This repository uses prettier for code styling rules and formatting. A pre-commit hook is installed automatically and configured to run prettier against all staged files as per the configuration in the project's package.json.

An additional npm script to run prettier (with write set to true) against all src and test project files is available by running:

npm run prettier

Installation

To start working with this package, clone the repository and run npm install.

In order to build the project run grunt dev or grunt dist.

Testing

Test cases MUST be written using Intern using the Object test interface and Assert assertion interface.

90% branch coverage MUST be provided for all code submitted to this repository, as reported by istanbul’s combined coverage results for all supported platforms.

Download Details: 

Author: dojo
Source Code: https://github.com/dojo/loader 
License: View license

#javascript #loader 

SVMLightLoader.jl: Loader Of Svmlight / Liblinear format Files

SVMLightLoader

The Loader of svmlight / liblinear format files

Usage

using SVMLightLoader


# load the whole file
vectors, labels = load_svmlight_file("test.txt")

# the vector dimension can be specified
ndim = 20
vectors, labels = load_svmlight_file("test.txt", ndim)
println(size(vectors, 1))  # 20

# iterate the file line by line
for (vector, label) in SVMLightFile("test.txt")
    dosomething(vector, label)
end

for (vector, label) in SVMLightFile("test.txt", ndim)
    dosomething(vector, label)
end

Author: IshitaTakeshi
Source Code: https://github.com/IshitaTakeshi/SVMLightLoader.jl 
License: View license

#julia #loader #files 

Screen_loader: Easy to Use Mixin ScreenLoader

screen_loader

Why ScreenLoader?

1. With the help of stream_mixin, it shows and hides the loader without updating the state of the widget which increases the performance
2. It does not push any sort of widget to navigation stack, this helps in not messing up the navigation stack and context
3. Easy to use, just use your screen with ScreenLoader mixin and wrap the widget with loadableWidget
4. The loader is customizable. You can use any widget as a loader
5. You can configure same loader for all the screens at once
6. You can also configure different loader for different screens

Basic usage

1. Use your screen with the ScreenLoader mixin
2. Wrap the widget with loadableWidget
3. Use performFuture function to show loader while your future is being performed

Configure different loader for individual screen

Simply overide loader() method

loader() {
    // here any widget would do
    return AlertDialog(
        title: Text('Wait.. Loading data..'),
    );
}

Configure the loader for all screens at once

void main() {
  configScreenLoader(
    loader: AlertDialog(
      title: Text('Gobal Loader..'),
    ),
    bgBlur: 20.0,
  );
  runApp(MyApp());
}

Priority of loaders (highest first)

• Local loader: the one you override in your widget
• Global loader: the one you specify in configScreenLoader. Note: if you don't override local(), this loader will be used
• Default loader: if you don't specify global loader or override local loader, this loader will be used

Migration guide to 4.0.0

1. ScreenLoaderApp widget is removed. Now no need to wrap your App around any widget just to set the global configurations. Instead call configScreenLoader() before runApp()

-void main() => runApp(MyApp());
+void main() {
+  configScreenLoader(
+    loader: AlertDialog(
+      title: Text('Gobal Loader..'),
+    ),
+    bgBlur: 20.0,
+  );
+  runApp(MyApp());
+}
 
 class MyApp extends StatelessWidget {
   @override
   Widget build(BuildContext context) {
-    return ScreenLoaderApp(
-      app: MaterialApp(
-        debugShowCheckedModeBanner: false,
-        title: 'Screen Loader',
-        theme: ThemeData(
-          primarySwatch: Colors.blue,
-        ),
-        home: Screen(),
-      ),
-      globalLoader: AlertDialog(
-        title: Text('Gobal Loader..'),
+    return MaterialApp(
+      debugShowCheckedModeBanner: false,
+      title: 'Screen Loader',
+      theme: ThemeData(
+        primarySwatch: Colors.blue,
       ),
-      globalLoadingBgBlur: 20.0,
+      home: Screen(),
     );
   }
 }

1. Instead of replacing the build function with screen use the build function itself and wrap the widget you want to show loader on with the loadableWidget.

-class _ScreenState extends State<Screen> with ScreenLoader<Screen> {
+class _ScreenState extends State<Screen> with ScreenLoader {
   @override
   loader() {
     return AlertDialog(
@@ -49,17 +51,19 @@ class _ScreenState extends State<Screen> with ScreenLoader<Screen> {
   }
 
   @override
-  Widget screen(BuildContext context) {
-    return Scaffold(
-      appBar: AppBar(
-        title: Text('ScreenLoader Example'),
-      ),
-      body: _buildBody(),
-      floatingActionButton: FloatingActionButton(
-        onPressed: () async {
-          await this.performFuture(NetworkService.getData);
-        },
-        child: Icon(Icons.refresh),
+  Widget build(BuildContext context) {
+    return loadableWidget(
+      child: Scaffold(
+        appBar: AppBar(
+          title: Text('ScreenLoader Example'),
+        ),
+        body: _buildBody(),
+        floatingActionButton: FloatingActionButton(
+          onPressed: () async {
+            await this.performFuture(NetworkService.getData);
+          },
+          child: Icon(Icons.refresh),
+        ),
       ),
     );
   }

Installing

Use this package as a library

Depend on it

Run this command:

With Flutter:

 $ flutter pub add screen_loader

This will add a line like this to your package's pubspec.yaml (and run an implicit flutter pub get):

dependencies:
  screen_loader: ^4.0.1

Alternatively, your editor might support flutter pub get. Check the docs for your editor to learn more.

Import it

Now in your Dart code, you can use:

import 'package:screen_loader/screen_loader.dart';

example/main.dart

import 'package:flutter/material.dart';
import 'package:screen_loader/screen_loader.dart';

void main() {
  configScreenLoader(
    loader: AlertDialog(
      title: Text('Gobal Loader..'),
    ),
    bgBlur: 20.0,
  );
  runApp(MyApp());
}

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      debugShowCheckedModeBanner: false,
      title: 'Screen Loader',
      theme: ThemeData(
        primarySwatch: Colors.blue,
      ),
      home: Screen(),
    );
  }
}

class Screen extends StatefulWidget {
  @override
  _ScreenState createState() => _ScreenState();
}

/// A Stateful screen
class _ScreenState extends State<Screen> with ScreenLoader {
  @override
  loader() {
    return AlertDialog(
      title: Text('Wait.. Loading data..'),
    );
  }

  @override
  loadingBgBlur() => 10.0;

  Widget _buildBody() {
    return Center(
      child: Icon(
        Icons.home,
        size: MediaQuery.of(context).size.width,
      ),
    );
  }

  @override
  Widget build(BuildContext context) {
    return loadableWidget(
      child: Scaffold(
        appBar: AppBar(
          title: Text('ScreenLoader Example'),
        ),
        body: _buildBody(),
        floatingActionButton: FloatingActionButton(
          onPressed: () async {
            await this.performFuture(NetworkService.getData);
          },
          child: Icon(Icons.refresh),
        ),
      ),
    );
  }
}

/// A Stateless screen
class BasicScreen extends StatelessWidget with ScreenLoader {
  BasicScreen({Key? key}) : super(key: key);

  @override
  Widget build(BuildContext context) {
    return loadableWidget(
      child: Scaffold(
        appBar: AppBar(
          title: Text('Basic ScreenLoader Example'),
        ),
        body: Center(
          child: Icon(
            Icons.home,
            size: MediaQuery.of(context).size.width,
          ),
        ),
        floatingActionButton: FloatingActionButton(
          onPressed: () async {
            await this.performFuture(NetworkService.getData);
          },
          child: Icon(Icons.refresh),
        ),
      ),
    );
  }
}

class NetworkService {
  static Future getData() async {
    return await Future.delayed(Duration(seconds: 2));
  }
}

PS

• PRs are welcome
• Please raise issues on https://github.com/arnold-parge/screen_loader.
• Open for suggestions ❤️

Original article source at: https://pub.dev/packages/screen_loader 

#flutter #dart #screen #loader 

Global_loader: A Flutter Package Which Will Start Global Loader

global_loader

A Flutter Package which will start Global Loader from any where in your code.

Screenshots

Usage

Example

To use this package:

• add the dependency to your pubspec.yaml file.

    dependencies:
      flutter:
        sdk: flutter
      global_loader: ^0.0.1

How to use

   
class HomePage extends StatefulWidget {
  const HomePage({Key? key}) : super(key: key);

  @override
  _HomePageState createState() => _HomePageState();
}

class _HomePageState extends State<HomePage> {
  GlobalLoader globalLoader = new GlobalLoader();
  
 

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      body: Center(
        child: Row(
          mainAxisAlignment: MainAxisAlignment.spaceEvenly,
          crossAxisAlignment: CrossAxisAlignment.center,
          children: [
            InkWell(
                onTap: () {
                  // This code helps fancy loader.
                  globalLoader.startFancyLoader(60,60);


                },
                child: Container(
                    alignment: Alignment.center,
                    height: 50,
                    width: 150,
                    decoration: BoxDecoration(
                        color: Colors.blue,
                        borderRadius: BorderRadius.circular(20)),
                    child: Text(
                      "Start",
                      style: TextStyle(
                          color: Colors.white,
                          fontSize: 18,
                          fontWeight: FontWeight.bold),
                    ))),
            InkWell(
                onTap: () {
                    // this line will stop your current loader.
                  globalLoader.stop();
                },
                child: Container(
                    alignment: Alignment.center,
                    height: 50,
                    width: 150,
                    decoration: BoxDecoration(
                        color: Colors.blue,
                        borderRadius: BorderRadius.circular(20)),
                    child: Text(
                      "Stop",
                      style: TextStyle(
                          color: Colors.white,
                          fontSize: 18,
                          fontWeight: FontWeight.bold),
                    )))
          ],
        ),
      ),
    );
  }
}

Getting Started

This project is a starting point for a Dart package, a library module containing code that can be shared easily across multiple Flutter or Dart projects.

For help getting started with Flutter, view our online documentation, which offers tutorials, samples, guidance on mobile development, and a full API reference.

Use this package as a library

Depend on it

Run this command:

With Flutter:

 $ flutter pub add global_loader

This will add a line like this to your package's pubspec.yaml (and run an implicit flutter pub get):

dependencies:
  global_loader: ^0.0.2

Alternatively, your editor might support flutter pub get. Check the docs for your editor to learn more.

Import it

Now in your Dart code, you can use:

import 'package:global_loader/global_loader.dart';

Author: Chandan123-pradhan
Source Code: https://github.com/chandan123-pradhan/Global-Loader 
License: MIT license

#flutter #dart #loader 

Jest Transformer Mimicking Webpack-contrib/raw-loader's Functionality

jest-raw-loader

Jest transformer mimicking webpack-contrib/raw-loader's functionality

Install

$ npm install --save-dev jest-raw-loader

Usage

Use jest's transform configuration options to use this package in your unit tests.

For example use the following to raw load .md and .graphql files:

"jest": {
  "transform": {
    "\\.graphql$": "jest-raw-loader",
    "\\.md$": "jest-raw-loader"
  }
}

Author: Keplersj
Source Code: https://github.com/keplersj/jest-raw-loader 
License: MIT license

#javascript #jest #loader 

TSM: TypeScript Module Loader

TypeScript Module Loader

Features

• Supports node <file> usage
• Supports ESM --loader usage†
• Supports --require hook usage
• Optional configuration file for per-extension customization

† The ESM Loader API is still experimental and will change in the future.

Install

# install as project dependency
$ npm install --save-dev tsm

# or install globally
$ npm install --global tsm

Usage

Note: Refer to /docs/usage.md for more information.

# use as `node` replacement
$ tsm server.ts

# forwards any `node` ENV or flags
$ NO_COLOR=1 tsm server.ts --trace-warnings

# use as `--require` hook
$ node --require tsm server.tsx
$ node -r tsm server.tsx

# use as `--loader` hook
$ node --loader tsm main.jsx

Author: lukeed
Source Code: https://github.com/lukeed/tsm 
License: MIT license 

#node #typescript #loader #javascript 

Cjs-loader: Node.js Loader for Compiling ESM & TypeScript Modules

cjs-loader

Node.js require() hook to instantaneously transform ESM & TypeScript to CommonJS on demand using esbuild.

Features

• Transforms ESM & TypeScript to CommonJS on demand
• Supports TS extensions .cjs & .mjs (.cts & .mts)
• Cached for performance boost
• Supports Node.js v12.16.2+
• Handles node: import prefixes

Tip:

cjs-loader doesn't hook into dynamic import() calls.

Use this with esm-loader for import() support. Alternatively, use tsx to handle them both automatically.

Install

npm install --save-dev @esbuild-kit/cjs-loader

Usage

Pass @esbuild/cjs-loader into the --require flag

node -r @esbuild/cjs-loader ./file.js

TypeScript configuration

The following properties are used from tsconfig.json in the working directory:

• jsxFactory
• jsxFragmentFactory

Cache

Modules transformations are cached in the system cache directory (TMPDIR). Transforms are cached by content hash so duplicate dependencies are not re-transformed.

Set environment variable ESBK_DISABLE_CACHE to a truthy value to disable the cache:

ESBK_DISABLE_CACHE=1 node -r @esbuild/cjs-loader ./file.js

Related

tsx - Node.js runtime powered by esbuild using @esbuild-kit/cjs-loader and @esbuild-kit/esm-loader.

@esbuild-kit/esm-loader - TypeScript to ESM transpiler using the Node.js loader API.

Author: ESbuild-kit
Source Code: https://github.com/esbuild-kit/cjs-loader 
License: 

#node #typescript #esbuild #loader 

ESm-loader: Node.js Loader for Compiling TypeScript Modules to ESM

esm-loader

Node.js import hook to instantaneously transform TypeScript to ESM on demand using esbuild.

Features

• Transforms TypeScript to ESM on demand
• Classic Node.js resolution (extensionless & directory imports)
• Cached for performance boost
• Supports Node.js v12.20.0+
• Handles node: import prefixes

Tip:

esm-loader doesn't hook into require() calls or transform CommonJS files (.js in commonjs package, .cjs, .cts).

Use this with cjs-loader for CommonJS support. Alternatively, use tsx to handle them both automatically.

Install

npm install --save-dev @esbuild-kit/esm-loader

Usage

Pass @esbuild-kit/esm-loader into the --loader flag.

node --loader @esbuild-kit/esm-loader ./file.ts

TypeScript configuration

The following properties are used from tsconfig.json in the working directory:

• jsxFactory
• jsxFragmentFactory

Cache

Modules transformations are cached in the system cache directory (TMPDIR). Transforms are cached by content hash so duplicate dependencies are not re-transformed.

Set environment variable ESBK_DISABLE_CACHE to a truthy value to disable the cache:

ESBK_DISABLE_CACHE=1 node --loader @esbuild-kit/esm-loader ./file.ts

FAQ

Can it import JSON modules?

Yes. This loader transpiles JSON modules so it's also compatible with named imports.

Can it import ESM modules over network?

Node.js has built-in support for network imports behind the --experimental-network-imports flag.

You can pass it in with esm-loader:

node --loader @esbuild-kit/esm-loader --experimental-network-imports ./file.ts

Can it resolve files without an extension?

In ESM, import paths must be explicit (must include file name and extension).

For backwards compatibility, this loader adds support for classic Node resolution for extensions: .js, .json, .ts, .tsx, .jsx. Resolving a index file by the directory name works too.

import file from './file' // -> ./file.js
import directory from './directory' // -> ./directory/index.js

Related

tsx - Node.js runtime powered by esbuild using @esbuild-kit/cjs-loader and @esbuild-kit/esm-loader.

@esbuild-kit/cjs-loader - TypeScript & ESM to CJS transpiler using the Node.js loader API.

Author: ESbuild-kit
Source Code: https://github.com/esbuild-kit/esm-loader 
License: 

#node #typescript #loader