This is an attempt to implement a framework-agnostic component authoring system by way of a build toolchain that compiles vanilla WebComponents and Svelte templates into modules which natively work with a range of popular frontend libraries.
WIP! functionality incomplete.
For your UI components to be recognised and correctly processed by this tool, please ensure that there is a package.json
file in each module folder that you wish to be processed. The main
field of each package file should reference either a JavaScript module containing a raw WebComponent (authored using any JS framework of your choice); or a raw Svelte component ready to be processed by the Svelte compiler.
Since the goal of this tool is to reduce integration complexity, there are a few other aspects you should be aware of if you use a more advanced build setup:
For these reasons, we recommend that you run any pre-compile steps needed to generate pure-JS versions of your component dependencies before running this build script, and reference the *.js
version of all related modules from your component files rather than other source file formats.
The CLI performs the following operations:
SOURCE_DIRECTORY
to search for source Web Components.DEST_DIRECTORY
for placing the output files.svelte.config.js
file in the current working directory, if present.template-*
directories in this module.package.json
files under the SOURCE_DIRECTORY
, without recursing into node_modules
directories.COMPONENT_OUTPUT_DIR
is determined by mapping the package file's path relative to the DEST_DIRECTORY
.COMPONENT_OUTPUT_DIR
according to the type of package detected:main
field in package.json
is omitted or points to a *.js
or *.mjs
file, the package is assumed to be a ready-to-deploy standards compliant Web Component. COMPONENT_OUTPUT_DIR
.HTMLElement
class definition as its default export.main
field points to a *.svelte
file, the package is assumed to be a Svelte component authored using the Svelte syntax.COMPONENT_OUTPUT_DIR
.main
source file, and it (along with its dependencies) is written to COMPONENT_OUTPUT_DIR
.ssr
build is run by the Svelte compiler and the output (along with all dependencies) is written to COMPONENT_OUTPUT_DIR/ssr
. The filename is the same as that generated for the Web Component version.package.json
file is loaded into a pkg
template variable.template-wc
EJS template files are processed against pkg
and output to COMPONENT_OUTPUT_DIR
, overwriting any existing files.package.json
metadata for the resulting generated WebComponent in COMPONENT_OUTPUT_DIR
is loaded and made available via the componentPkg
template variable.template-ssr
EJS template files are processed against pkg
and output to COMPONENT_OUTPUT_DIR/ssr
, overwriting any existing files.template-
${templateId}
) is provided via the componentType
template variable. This will be a string like 'angular'
, 'react'
, 'vue'
etc.pkg
, componentPkg
& componentType
; and output to the destination base folder under a componentType
subdirectory.Upon completion, you will end up with a set of nodejs packages that are wrapped to be natively compatible with various runtimes.
Pre-build clean steps and publish workflows are currently left as an exercise to the reader.
mycomponentlib
, mycomponentlib-react
, mycomponentlib-angular
etc)ReactComponent
) without additional runtime or compile-time dependenciesSuch a development pipeline is most useful for those wishing to author UI component kits that can be easily dropped in to other projects. For those wishing only to build Svelte components, or to simply integrate Svelte components into their existing app built with another framework, this is not what you're looking for.
For more information on what sparked this effort, see svelte#4117.
Apache 2.0