Exciting release!Introducing "safe npm". Learn more
Log inDemoInstall


Package Overview
File Explorer

Advanced tools


Lit-based web component for displaying text and editing it directly.


Version published
Weekly downloads
decreased by-74.17%

Weekly downloads




2.1.1 (2023-03-06)

Bug Fixes

  • remove script (#152) (b111cc1)




NPM version

Note: this is a "labs" component. While functional, these tasks are prerequisites to promotion to BrightspaceUI "official" status:

A Lit element web component for displaying text and editing it in-place.

animated screenshot of edit in place component


To install from NPM:

npm install @brightspace-ui-labs/edit-in-place


<script type="module"> import '@brightspace-ui-labs/d2l-labs-edit-in-place.js'; </script> <d2l-labs-edit-in-place placeholder="Edit Me"></d2l-labs-edit-in-place>


  • value (String): value of the input
  • placeholderString, default: 'Enter a value'): placeholder text of the input. If value is blank, this appears in italics as the label. placeholder must not be blank.
  • size(Number): length of the input
  • maxlength(Number): imposes an upper character limit
  • readonly(Boolean): The label will behave like a simple text element if true.


The d2l-labs-edit-in-place dispatches the change event when text is saved via pressing the Enter key while focusing the input, or by pressing the save button:

editInPlace.addEventListener('change', (e) => { console.log(editInPlace.value); });


d2l-labs-edit-in-place can be used in headers and other section-related elements by wrapping it within the desired element:

<script type="module"> import '@brightspace-ui-labs/edit-in-place/edit-in-place.js'; </script> <h2> <d2l-labs-edit-in-place placeholder="Edit Me"></d2l-labs-edit-in-place> </h2>

Developing, Testing and Contributing

After cloning the repo, run npm install to install dependencies.

Running the demos

To start a web-dev-server that hosts the demo page and tests:

npm start

The demo page can be found at http://localhost:8000/demo/d2l-labs-edit-in-place.html. Note the port number your shell outputs; If it differs from the above URL, change the URL accordingly.


To lint (eslint):

npm run lint

To run unit tests locally using Web Test Runner:

npm run test:headless

To run both lint AND local unit tests:

npm test

Versioning & Releasing

TL;DR: Commits prefixed with fix: and feat: will trigger patch and minor releases when merged to main. Read on for more details...

The semantic-release GitHub Action is called from the release.yml GitHub Action workflow to handle version changes and releasing.

Version Changes

All version changes should obey semantic versioning rules:

  1. MAJOR version when you make incompatible API changes,
  2. MINOR version when you add functionality in a backwards compatible manner, and
  3. PATCH version when you make backwards compatible bug fixes.

The next version number will be determined from the commit messages since the previous release. Our semantic-release configuration uses the Angular convention when analyzing commits:

  • Commits which are prefixed with fix: or perf: will trigger a patch release. Example: fix: validate input before using
  • Commits which are prefixed with feat: will trigger a minor release. Example: feat: add toggle() method
  • To trigger a MAJOR release, include BREAKING CHANGE: with a space or two newlines in the footer of the commit message
  • Other suggested prefixes which will NOT trigger a release: build:, ci:, docs:, style:, refactor: and test:. Example: docs: adding README for new component

To revert a change, add the revert: prefix to the original commit message. This will cause the reverted change to be omitted from the release notes. Example: revert: fix: validate input before using.


When a release is triggered, it will:

  • Update the version in package.json
  • Tag the commit
  • Create a GitHub release (including release notes)
  • Deploy a new package to NPM

Releasing from Maintenance Branches

Occasionally you'll want to backport a feature or bug fix to an older release. semantic-release refers to these as maintenance branches.

Maintenance branch names should be of the form: +([0-9])?(.{+([0-9]),x}).x.

Regular expressions are complicated, but this essentially means branch names should look like:

  • 1.15.x for patch releases on top of the 1.15 release (after version 1.16 exists)
  • 2.x for feature releases on top of the 2 release (after version 3 exists)


Last updated on 06 Mar 2023

Did you know?

Socket installs a Github app to automatically flag issues on every pull request and report the health of your dependencies. Find out what is inside your node modules and prevent malicious activity before you update the dependencies.

Install Socket
support@socket.devSocket SOC 2 Logo


  • Package Issues
  • Integrations
  • Docs
  • Pricing
  • FAQ
  • Roadmap

Stay in touch

Get open source security insights delivered straight into your inbox.

  • Terms
  • Privacy
  • Security

Made with ⚡️ by Socket Inc