Is your feature request related to a problem? Please describe. At that time slinkity lacks of PostCSS support. I know sass supports a huge amount of things, but this is not the only solution to write styles. In my opinion sass or scss syntax with things like some monsterous mixins just slows donw DX. In PostCSS you just install required plugin, set options and continue write your styles with some new magical property or function. In most cases I doesn't need all this sass things like nesting. I can add only a few needed number of this with PostCSS. This time all that stuff like automatic fallbacks for properties, custom functions, sass-like variables in plain css and of course Tailwind we can't use. Eleventy have templating in markdown, lets add the same functionality to css.

Describe the solution you'd like Implement slinkity as a plugin or config like in 61#. Then we can pass PostCSS config to vites css.postcss options. With plain vite I usually add postcss.config.js path and all works fine. As soon this feature will be implemented then all tailwind stuff will be working automagically.

Describe alternatives you've considered Check for an existence of postcss.config.js and pass this if exists to vites css.postcss. But slinkity config seems more viable solution than that.

Additional context

• Tailwind installation and setup
• Vite: css.postcss

Update: 03.16.22

This issue turned into a whole separate discussion on supporting 11ty image at all when using Slinkity. We arrived at a pretty simple solution: expose the intermediate 11ty directory during production builds so images are preserved. This is now resolved!

Original issue (now a will-not-fix!)

Is your feature request related to a problem? Please describe.

There is no current solution for including images in the Slinkity documentation.

Describe the solution you'd like

Something that will let us easily drop in images without having to worry about manually optimizing for size or responsiveness.

Describe alternatives you've considered

Ben suggested copying the image shortcode from their docs as the easiest way to get this setup.

Additional context

This is mostly a note for myself, but if anyone wants to take this on in the next week or two before I get to it then it should make for a pretty simple PR.

Is your feature request related to a problem? Please describe. I want to have finer control over when my component is hydrated on the page. I expect these 5 methods from Astro's partial hydration to work:

• load: Hydrate when the DOM is finished parsing
• idle: Hydrate when the main thread is no longer busy (aka DOM is done parsing, and any JS outside my component is finished running)
• visible: Hydrate when my component has scrolled into view
• media: Hydrate when a media query is met
• none: Never hydrate

Describe the solution you'd like I'd like to see a new API similar to Astro's client:property helper. We'll use some new naming for Slinkity though:

Prop name change: hydrate (instead of Astro's client)

• this describes the "purpose" of the prop better than client in my opinion: to hydrate your static markup
• ties directly into the feature's name on our documentation: Partial Hydration
• hey, hydrate or diedrate am I right?

Comparison of Astro and Slinkity syntax

Astro:

import ReactComponent from '...'
---

<ReactComponent client:visible />

Slinkity:

{% react 'components/ReactComponent' hydrate="lazy" %}

Value naming

| Slinkity | Astro | | --------|-------| | eager | load | | lazy | visible | | none | [empty] |

• we changed visible to lazy because a) visible could be associated with the display and visibility properties in CSS (which can cause confusion), and b) this feature is often compared to lazy image loading in the DOM. Yes, lazy is often an overloaded term in CS. But if we're going to choose a short and concise name, why not choose something similar to existing browser features?
• we also changed load to eager to add a yin to lazy's yang. It also made less sense to use load after switching from client to hydrate for the prop name (i.e. client:load makes sense, but hydrate="load" doesn't as much)
• we allow hydrate="none" as a potential value, since we will allow users to choose a default hydration method for their project (but no hydration is the default!). Including a "none" allows users to override whatever default they've chosen to opt-out of hydration

Handling idle, media, etc

You may have noticed a few hydration modes like idle, media, and client:only are missing from that table. Well, we have a special plan for those... check out this proposal in the comments 😄

Describe the bug

I'm getting the following error when trying to migrate to Slinkity:

[11ty] > Having trouble writing template: false

`TemplateWriterWriteError` was thrown
[11ty] > The "to" argument must be of type string. Received type boolean (false)

`TypeError` was thrown:
[11ty]     TypeError [ERR_INVALID_ARG_TYPE]: The "to" argument must be of type string. Received type boolean (false)
        at new NodeError (node:internal/errors:371:5)
        at validateString (node:internal/validators:119:11)
        at relative (node:path:1192:5)
        at Object.<anonymous> (//path/to/project/node_modules/slinkity/lib/plugin/index.js:140:30)
        at Template.runTransforms (//path/to/project/node_modules/@11ty/eleventy/src/Template.js:527:38)
        at async Template.renderPageEntry (//path/to/project/node_modules/@11ty/eleventy/src/Template.js:802:15)
        at async //path/to/project/node_modules/@11ty/eleventy/src/Template.js:827:21
        at async Promise.all (index 0)
        at async Promise.all (index 6)

I suspect this is related to #84. I have the following permalink: falses:

• https://github.com/AleksandrHovhannisyan/aleksandrhovhannisyan.com/blob/slinkity/src/_art/_art.json#L3
• https://github.com/AleksandrHovhannisyan/aleksandrhovhannisyan.com/blob/slinkity/src/_licenses/_licenses.json#L2

Removing these allows the server to start.

To Reproduce

1. Clone https://github.com/AleksandrHovhannisyan/aleksandrhovhannisyan.com.
2. Check out the slinkity branch/
3. Run yarn to install dependencies.
4. Run yarn serve to start up the slinkity server.
5. Observe the error early on in the output.

Expected behavior The error shouldn't occur 😄

(please complete the following information):

• OS: Windows 10 (WSL)
• 11ty version: beta 5

fixes: #65

• Split out applyViteHtmlTransform into its own file, so it was easier to test.
• Added optional chaining to insertAdjacentHTML in case HTML gets through without a body.
• Added a check for .html at the start of applyViteHtmlTransform, returning just the content if we are not processing HTML.
• Refactored the NPM scripts to not specify /src so singular tests can be run more easily from the command line with npm t <test-file-pattern>. Currently, if you were to do that it would run every test.
  • Hope you don't mind this one, it is not related to the functionality fix. More of quality of life DX thing. Happy to remove it if you want to keep this PR focused.

Describe the bug

Suppose you have a React component like this:

_includes/components/Test/index.jsx

import styles from './styles.css';
const Test = () => <div/>;

with this CSS:

_includes/components/Test/styles.css

div { background: white; }

And statically render it in Slinkity:

index.njk

{% react 'components/Test/index', render='static' %}

In dev mode, this works perfectly and bundles the CSS as part of the final stylesheet.

In prod mode, the imported styles disappear.

To Reproduce

1. Clone this repo: https://github.com/AleksandrHovhannisyan/slinkity-bug-112
2. Run yarn to install dependencies.
3. Run yarn start to start dev mode. Observe a white square (component-scoped CSS) on a black background (static global CSS).
4. Run rm -rf _site to purge output.
5. Run yarn build to build for prod.
6. Open _site and observe that the stylesheet only contains the global static CSS, not any of the component's CSS.

Expected behavior

Statically imported CSS should be bundled in the final stylesheet.

Additional context

• Disabling static rendering for the component fixes the issue.
• Observed with CSS, CSS modules, and Sass.

Describe the bug The eleventy-base-blog has nunjucks templates that generate both XML and JSON feeds for RSS readers. When using Slinkity in place of eleventy these fail to build.

To Reproduce Steps to reproduce the behavior:

1. Go to https://stackblitz.com/github/AndrewLeedham/eleventy-base-blog-slinkity
2. Run npm run build in the terminal.
3. See the issue.

Expected behavior Slinkity to work out-the-box with the eleventy-starter-blog.

Logs

[11ty] Problem writing Eleventy templates: (more in DEBUG output)
[11ty] > Having trouble writing template: .11ty-build-YLF9VP/sitemap.xml

`TemplateWriterWriteError` was thrown
[11ty] > Cannot read properties of null (reading 'insertAdjacentHTML')

`TypeError` was thrown:
[11ty]     TypeError: Cannot read properties of null (reading 'insertAdjacentHTML')
        at applyViteHtmlTransform (/home/projects/jvmiqqwvx.github/node_modules/slinkity/lib/plugin/index.js:99:31)
        at Object.eval (/home/projects/jvmiqqwvx.github/node_modules/slinkity/lib/plugin/index.js:161:22)
        at Template.runTransforms (/home/projects/jvmiqqwvx.github/node_modules/@11ty/eleventy/src/Template.js:512:38)
        at async Template.renderPageEntry (/home/projects/jvmiqqwvx.github/node_modules/@11ty/eleventy/src/Template.js:787:15)
        at async eval (/home/projects/jvmiqqwvx.github/node_modules/@11ty/eleventy/src/Template.js:803:21)
        at async Promise.all (index 0)
        at async Promise.all (index 1)

(please complete the following information):

• OS: macOS 11.2.3
• Browser: Chrome 95
• Version: 0.2.0

Additional context Seems to me that Vite is assuming the template is outputting HTML, but in this case, it is either XML or JSON which it does not understand.

Is your feature request related to a problem? Please describe. We currently use "plain" npm for everything in our repo. This comes with a few problems:

• slowest installation times of all available options
• nothing to help with managing workspaces, should we need them

Describe the solution you'd like I'd like to choose something faster and/or sexier for our project. pnpm seems to fit the bill according to this thread from Jared Palmer!

Describe alternatives you've considered Yarn v1 seems like a tried-and-true choice for speeding up local installs. Still, it suffers from:

• unique keywords that differ from npm like add instead of i. Some like this, but I personally think it hurts the beginner-friendliness for new contributors
• it's aging by comparison to Yarn v2 (which is a hassle to set up). Worth investigating v3 though.

Update: decided on Yarn 3 We've decided to use Yarn 3 instead given our team's existing familiarity with Yarn 1. Redwood's decision to use Yarn 3 gives us some confidence as well!

Describe the bug I took an existing repo, updated it to Eleventy 1.0.0-beta.2, changed it over from Tailwind to Sass, and then installed Slinkity and tried replacing the package.json Eleventy commands with Slinkity commands. On npm run start, I got the following error message (followed by many Vite-related items — e.g., 12:04:27 PM [vite] page reload with the specific HTML file it's presumably building — which implied rendering success otherwise):

(!) Could not auto-determine entry point from rollupOptions or html files and there are no explicit optimizeDeps.include patterns. Skipping dependency pre-bundling.
[Info] Now serving on port 3000 🚀
[Info] Visit http://localhost:3000 in your favorite browser (that isn't IE 😉)
(!) Could not auto-determine entry point from rollupOptions or html files and there are no explicit optimizeDeps.include patterns. Skipping dependency pre-bundling. (x2)

To Reproduce Steps to reproduce the behavior:

1. In package.json scripting, replace the Eleventy commands with Slinkity commands as per the Slinkity docs.
2. Execute the proper script (e.g., npm run start).
3. Note the error message as the script fails.

Expected behavior I expected the site to load in development mode.

Screenshots N/A

Versions

• OS: macOS 11.6
• Browser: N/A because site didn't load.
• Eleventy version: 1.0.0-beta.2
• Slinkity version: 0.1.10

Additional context Add any other context about the problem here.

Describe the bug

I'm trying to use a third-party component library that is delivered as ES modules.

To Reproduce

Steps to reproduce the behavior:

1. Start a new react-flavored slinkity project (quick start)
2. Install package: yarn add tick-tick
3. Import the esm modules: import { TickTick } from "tick-tick/esm/index";
4. Run npm run dev
5. See error

Expected behavior

I should be able to import modules from the package.

• OS: [Windows]
• Browser [Chrome]
• Version [0.8.2]

Additional context Here is the error I get initially:

[Browsersync] Serving files from: _site
@my-esm/package doesn't appear to be written in CJS, but also doesn't appear to be a valid ES module (i.e. it doesn't have "type": "module" or an .mjs extension for the entry point). Please contact the package author to fix.
2:07:57 PM [vite] Error when evaluating SSR module /@fs/home/jonbri/my-slinkity-site/node_modules/@babel/runtime/helpers/extends.js?v=2589198d:
ReferenceError: module is not defined

If I go ahead and "type": "module" to the third-party package's package.json I get this error message:

[Browsersync] Serving files from: _site
2:29:16 PM [vite] Error when evaluating SSR module /home/me/my-slinkity-site/src/_includes/Baz.jsx:
Error [ERR_UNSUPPORTED_DIR_IMPORT]: Directory import '/home/me/my-slinkity-site/node_modules/@my-esm/package/components/Button' is not supported resolving ES modules imported from /home/me/my-slinkity-site/node_modules/@my-esm/package/index.js
    at new NodeError (internal/errors.js:322:7)
    at finalizeResolution (internal/modules/esm/resolve.js:314:17)
    at moduleResolve (internal/modules/esm/resolve.js:776:10)
    at Loader.defaultResolve [as _resolve] (internal/modules/esm/resolve.js:887:11)
    at Loader.resolve (internal/modules/esm/loader.js:89:40)
    at Loader.getModuleJob (internal/modules/esm/loader.js:242:28)
    at ModuleWrap.<anonymous> (internal/modules/esm/module_job.js:76:40)
    at link (internal/modules/esm/module_job.js:75:36)

Is it possible to consume esm modules from node_modules? I assume we can because we can use esm import syntax in our local files (for example, within the _includes dir), but I'm nots seeing anything about this in the Slinkity doc.

Is your feature request related to a problem? Please describe.

I'd prefer to write as little nunjucks as possible. To that end, it would be nice to define my layout.njk with my nice neat react components like so:

<!DOCTYPE html>
<html lang="en">
  <head>
...
    {% component 'Footer.tsx' %}
  </body>
</html>

This works great until the engine is rendering something like a markdown file, in which case the front matter falls out of scope from what I can tell.

Describe the solution you'd like

I'm not sure if it's possible but it would be nice to have the current frontmatter in scope to pass to my footer for example:

    {% component 'Footer.tsx' frontmatter=frontmatter %}

Describe alternatives you've considered

Writing multiple base layouts, but seems gross.

I'm trying to use Slinkity to compile and import TS (or TSX) files, as I would using Vite.

My Slinkity project structure is something like this:

src/
  index.html
  app/
    index.ts
    SomeComponent.tsx
    OtherStuff.ts
    ...etc

I've tried to load index.ts from index.html in a variety of ways:

<script src="/app/index.ts" type="module"></script>
<script src="/src/app/index.ts" type="module"></script>
<script src="../src/app/index.ts" type="module"></script>

…but the dev server 404's on all of those, and Rollup is unable to resolve any of those paths at build time.

Is it possible to reference a TS file like this, as I would in Vite, or are we limited to using shortcodes in Slinkity?

Just wondering when Vite fires in the eleventy build process.

I've used a package with eleventy which also uses eleventy.after, and vite gets confused and doesn't render the effects of the package.

Is your feature request related to a problem? Please describe.

Hello, I have project where one .njk produces many page with the same Vue component, after building I'm getting the site with huge amount of same js files, one per each page that was generated by previously described .njk file. It enlarge process of Vite stage building and doesn't allow browser to work with cached of version of same content file.

Describe the solution you'd like

It would be nice if Slinkity generated included js file only once per project and imported it on each page with the same component.

Describe alternatives you've considered

Cant imagine other solution.

Is your feature request related to a problem? Please describe.

Inside Svelte <style lang="postcss"></style> blocks, PostCSS is not being used.

Describe the solution you'd like

I would like to configure svelte preprocess to use my PostCSS configuration

Describe alternatives you've considered

A workaround to override the svelte plugin config inside .eleventy.js

const svelteRenderer = require('@slinkity/renderer-svelte');
const { svelte } = require('@sveltejs/vite-plugin-svelte');
const preprocess = require('svelte-preprocess');
const renderer = {
    ...svelteRenderer,
    viteConfig() {
        const config = svelteRenderer.viteConfig();
        return {
            ...config,
            plugins: [
                svelte({
                    preprocess: preprocess({
                        postcss: {
                            configFilePath: '.'
                        }
                    }),
                    compilerOptions: {
                        hydratable: true
                    }
                })
            ]
        };
    }
};

module.exports = function (eleventyConfig) {
    eleventyConfig.setUseGitIgnore(false);
    eleventyConfig.addPlugin(
        slinkity.plugin,
        slinkity.defineConfig({
            renderers: [renderer]
        })
    );
    return {
        dir: {
            input: 'src',
            output: 'dist'
        }
    };
};

Additional context

Add any other context or screenshots about the feature request here.

Is your feature request related to a problem? Please describe.

Components can't really fetch data because that would make them asynchronous, and renderToStaticMarkup doesn't support that. If you could fetch data inside components, it would shift the responsibility of handling data closer to where it belongs.

Describe the solution you'd like

With React v18 you can use renderToPipeableStream, as it fully supports Suspense

Describe alternatives you've considered

I'm not sure if there's any other possibility to fetch data outside of pages? Or some workaround?

Additional context

Astro seems to be one of the very few frameworks that supports server-side data fetching inside components. I guess using asynchronous Suspense combined with React 18's async SSR rendering would be a working solution for slinkity.

Changes made

• Hoist viteSSR and componentAttrStore to the global scope. This prevents lookup mismatches in development (see inline comments on plugin.js for more info).
• Updates to componentAttrStore keying
  • Add a nested key based on "environment." This corresponds to the deployment directory for a set of routes. Ex. "_site" for static builds, netlify/functions/possum for serverless functions namespaced to "possum," etc
  • Key based on url in development builds. This lets us remove the janky outputPath -> url regex we used to use, and makes serverless build mapping much simpler!
• Add separate key / value pair for serverless builds based on the eleventy.serverlessUrlMap event. This is loosely inspired by the 11ty serverless source code since this event is undocumented!