ARG VARIANT="14-buster"

FROM mcr.microsoft.com/vscode/devcontainers/typescript-node:0-${VARIANT}

ENV EMSDK /emsdk

ENV EMSCRIPTEN_VERSION 2.0.15

RUN git clone https://github.com/emscripten-core/emsdk.git $EMSDK

RUN echo "## Install Emscripten" \

&& cd ${EMSDK} \

&& ./emsdk install ${EMSCRIPTEN_VERSION} \

&& echo "## Done"

RUN cd ${EMSDK} \

&& echo "## Generate standard configuration" \

&& ./emsdk activate $EMSCRIPTEN_VERSION \

&& chmod 777 ${EMSDK}/upstream/emscripten \

&& chmod -R 777 ${EMSDK}/upstream/emscripten/cache \

&& echo "int main() { return 0; }" > hello.c \

&& ${EMSDK}/upstream/emscripten/emcc -c hello.c \

&& cat ${EMSDK}/upstream/emscripten/cache/sanity.txt \

&& echo "## Done"

ENV PATH $EMSDK:$EMSDK/upstream/emscripten/:$PATH

RUN echo "## Aggressive optimization: Remove debug symbols" \

&& cd ${EMSDK} && . ./emsdk_env.sh \

# Remove debugging symbols from embedded node (extra 7MB)

&& strip -s `which node` \

# Tests consume ~80MB disc space

&& rm -fr ${EMSDK}/upstream/emscripten/tests \

# Fastcomp is not supported

&& rm -fr ${EMSDK}/upstream/fastcomp \

# strip out symbols from clang (~extra 50MB disc space)

&& find ${EMSDK}/upstream/bin -type f -exec strip -s {} + || true \

&& echo "## Done"

RUN echo ". /emsdk/emsdk_env.sh" >> /etc/bash.bashrc

RUN apt-get update \

&& apt-get install -y \

ca-certificates \

fonts-liberation \

libappindicator3-1 \

libasound2 \

libatk-bridge2.0-0 \

libatk1.0-0 \

libc6 \

libcairo2 \

libcups2 \

libdbus-1-3 \

libexpat1 \

libfontconfig1 \

libgbm1 \

libgcc1 \

libglib2.0-0 \

libgtk-3-0 \

libnspr4 \

libnss3 \

libpango-1.0-0 \

libpangocairo-1.0-0 \

libstdc++6 \

libx11-6 \

libx11-xcb1 \

libxcb1 \

libxcomposite1 \

libxcursor1 \

libxdamage1 \

libxext6 \

libxfixes3 \

libxi6 \

libxrandr2 \

libxrender1 \

libxss1 \

libxtst6 \

lsb-release \

wget \

xdg-utils

ENV RUN_WORKER_TEST_WITHOUT_PUPPETEER_SANDBOX=1

{

"name": "Node.js & TypeScript",

"build": {

"dockerfile": "Dockerfile",

// Update 'VARIANT' to pick a Node version: 10, 12, 14

"args": {

"VARIANT": "14"

},

},

// Set *default* container specific settings.json values on container create.

"settings": {},

// Add the IDs of extensions you want installed when the container is created.

"extensions": [

"dbaeumer.vscode-eslint"

],

// Use 'forwardPorts' to make a list of ports inside the container available locally.

// "forwardPorts": [],

// Use 'postCreateCommand' to run commands after the container is created.

// "postCreateCommand": "yarn install",

// Comment out connect as root instead. More info: https://aka.ms/vscode-remote/containers/non-root.

"remoteUser": "node"

}

name: 'Build SQL.js'

description: 'Builds sql.js using the .devcontainer/Dockerfile as its environment'

runs:

using: 'docker'

image: '../../../.devcontainer/Dockerfile'

entrypoint: "/github/workspace/.github/actions/build-sqljs/entrypoint.sh"

set -e

cd /github/workspace/

npm run rebuild

uses: ./.github/actions/build-sqljs

General consumers of this library don't need to read any further. (The compiled files are available via the [release page](https://github.com/sql-js/sql.js/releases).)

If you want to compile your own version of SQLite for WebAssembly, or want to contribute to this project, read on.

This project defines a standardized development environment using Docker (and the .devcontainer spec in particular). This allows for anyone on any platform to get up and running quickly. (VSCode is not technically required to make use of this standardized environment, but it makes containerized development so seamless that the non-VSCode path is not currently documented here.)

Standardizing our development environment has numerous benefits:

- Allows anyone on ANY platform (Linux, Mac, and Windows) to contribute or compile their own build.

- It's quicker and easier for any contributor to dive in and fix issues.

- (Practically) eliminates configuration bugs that are difficult for maintainers to reproduce. Also known as "works on my machine" issues.

- Allows us to write our scripts assuming that they're _always_ running in a single known environment of a single, known platform.

- Ensure that all contributors use a known, standardized installation of EMSDK.

- Allows for a more clearly documented process for updating the EMSDK to a new version.

- End-Users that simply want to compile and install their own version of SQLite don't have to bother with EMSDK installation in their particular environment.

To get started:

1. Follow the [Installation Steps for Containerized Development in VSCode](https://code.visualstudio.com/docs/remote/containers#_installation). This includes installing Docker, VSCode, and the [Remote Development extension pack](https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.vscode-remote-extensionpack) for VSCode)

2. Clone this repository

3. Open the repository folder in VSCode. It will detect the presence of a .devcontainer and prompt you: "Folder contains a Dev Container configuration file. Reopen folder to develop in a container." Click "Reopen in container"

You're now ready to test the dev environment:

4. Click on Terminal->New Terminal to be dropped into a terminal inside the dev environment.

5. Run `$ npm install` to install the required modules

6. Run `$ npm test` to ensure all tests pass

7. Run `$ npm rebuild` to re-compile the project from scratch (using the version of EMSDK installed in the container).

8. Run `$ npm test` to ensure all tests pass after said rebuild

You're now ready for development!

If you're on a Mac or Linux-based host machine, you can install and use the EMSDK directly to perform a build.

Note that if you run into bugs with this configuration, we highly encourage you to use the containerized development environment instead, as detailed above.

Instructions:

1. [Install the EMSDK](https://emscripten.org/docs/getting_started/downloads.html)

2. Clone this repository

3. Run `$ npm install` to install the required modules

4. Run `$ npm test` to ensure all tests pass

5. Run `$ npm rebuild` to re-compile the project from scratch (using the version of EMSDK installed in the container).

6. Run `$ npm test` to ensure all tests pass after said rebuild

In order to enable extensions like JSON1 or FTS5, change the CFLAGS in the [Makefile](Makefile) and run `npm run rebuild`:

``` diff

CFLAGS = \

-O2 \

-DSQLITE_OMIT_LOAD_EXTENSION \

-DSQLITE_DISABLE_LFS \

-DSQLITE_ENABLE_FTS3 \

-DSQLITE_ENABLE_FTS3_PARENTHESIS \

-DSQLITE_THREADSAFE=0

General consumers of this library don't need to read any further. (The compiled files are available via the [release page](https://github.com/sql-js/sql.js/releases).)

If you want to compile your own version of SQLite for WebAssembly, or want to contribute to this project, see [CONTRIBUTING.md](docs/CONTRIBUTING.md).

"rebuild": "npm run clean && npm run build",

"clean": "make clean",

const { env } = require("process");

const browser = await Worker.launchBrowser();

static async launchBrowser(){

try{

return await puppeteer.launch();

}

catch(e){

if (e.stack.includes('No usable sandbox!')){

// It's possible that this exception is n expected error related to not having the ability to create a sandboxed user for Puppeteer in Docker.

// One way around this is to set up the Dockerfile to have a sandboxed user.

// Details on getting Puppeteer running sandboxed while in Docker are here:

// https://github.com/puppeteer/puppeteer/blob/main/docs/troubleshooting.md#running-puppeteer-in-docker

// That seemed kinda complicated, so I'm working around it more quickly/straightforwardly by looking for an env variable we set in the Docker fil `RUN_WORKER_TEST_WITHOUT_PUPPETEER_SANDBOX`.

// -- Taytay

if (env['RUN_WORKER_TEST_WITHOUT_PUPPETEER_SANDBOX']=="1"){

// This tells puppeteer to launch without worrying about the sandbox.

// That's not "safe" if you don't trust the code you're loading in the browser,

// but we're in a container and we know what we're testing.

return await puppeteer.launch({args: ['--no-sandbox', '--disable-setuid-sandbox']});

}

else {

console.warn("Puppeteer can't start due to a sandbox error. (Details follow.)\nFor a quick, but potentially dangerous workaround, you can set the environment variable 'RUN_WORKER_TEST_WITHOUT_PUPETEER_SANDBOX=1'.\nYou can also simply run this test in the Docker container defined in .devcontainer/Dockerfile.");

}

}

// If we're here, we couldn't get out of this cleanly. Re-throw

throw e;

}

}